Exists any naming guideline for naming columns at Sql Server? I searched at MSDN, but dont found anything, just for .Net
There are lots of different conventions out there (and I'm sure other answers may make some specific suggestions) but I think that the most important thing is that you be consistent. If you are going to use a prefix for something, use it everywhere. If you are going to have a foreign key to another table, use the same column name everywhere. If you are going to separate words with underscores, do that everywhere.
In other words, if someone looks at a few tables, they should be able to extrapolate out and guess the names of other tables and columns. It will require less mental processing to remember what things are called.
There are many resources out there, but nothing that I have been able to truly pin down as a SQL Server specific set or anything published by Microsoft.
However, I really like this list.
Also, very important to NOT start out stored procedures with sp_
To be 100% honest though, the first part of my posted link is the most important. It must make sense for your organization, application, and implementation.
As always, google is your friend...
I find the following short list helpful:
Name tables as pluralnouns (or singular, but as a previous response stated, be consistent) for example "Customers", "Orders", "LineItems"
Stored procedures should be named without any prefixes such as "sp_" since SQL Server uses the "sp_" prefix to denote special meaning for system procedures.
Name columns as though as you would name attributes on a class (without using underscores)
Try not to use space characters in naming columns or database entities since you would have to escape all names with "[...]"
Many-to-many tables: for example "CustomerOrders"
Related
I'm learning about SQL databases so that I can work on an existing database, and I noticed this naming convention used on a lot of the files.
I'm thinking usp stands for User Stored Procedures, but I'm not entirely certain what parmsel is for. I've tried looking this up and see others using it with the case parmSel...
So what does usp_parmsel stand for?
The files are named like so under Programmability > Stored Procedures in the SQL Object Explorer:
dbo.usp_parmsel_CustomerExists
dbo.usp_parmsel_CustomerReferral
dbo.usp_parmsel_CustomerReceipt
Thanks!
Parmsel stands for parameter selector. You can look up parameter selectors on an engine search machine.
Apparently The PARMSEL field determines the format of the remainder of the area.
There is very vague information about it online.
Maybe this? https://documentation.devexpress.com/#CodeRush/CustomDocument1524
I was finally able to verify 100% with a higher up-- it stands for Parameter Select.
I saw a few places online where this was used, it looks like a rather old naming convention-- which makes sense, I'm working with an old system.
What is a scenario that exemplifies a good reason to use prefixes, such as fn_GetName, on function names in SQL Server? It would seem that it would be unnecessary since usually the context of its usage would make it clear that it's a function. I have not used any other language that has ever needed prefixes on functions, and I can't think of a good scenario that would show why SQL is any different.
My only thinking is that perhaps in older IDE's it was useful for grouping functions together when the database objects were all listed together, but modern IDE's already make it clear what is a function.
You are correct about older IDEs
As a DBA, trying to fix permissions using SQL Server Enterprise Manager (SQL Server 2000 and 7.0), it was complete bugger trying to view permissions. If you had ufn or usp or vw it became easier to group things together because of how the GUI presented the data.
Saying that, if you have SELECT * FROM Thing, what is Thing? A view or a table? It may work for you as a developer but it will crash when deployed because you don't grant permissions on the table itself: only views or procs. Surely a vwThing will keep your blood pressure down...?
If you use schemas, it becomes irrelevant. You can "namespace" your objects. For example, tables in "Data" and other objects per client in other schemas eg WebGUI
Edit:
Function. You have table valued and scalar functions. If you stick with the code "VerbNoun" concept, how do you know which is which without some other clue. (of course, this can't happen because object names are unique)
SELECT dbo.GetName() FROM MyTable
SELECT * FROM dbo.GetName()
If you use a plural to signify a table valued function, this is arguably worse
SELECT dbo.GetName() FROM MyTable
SELECT * FROM dbo.GetNames()
Whereas this is less ambiguous, albeit offensive to some folk ;-)
SELECT dbo.sfnGetName() FROM MyTable
SELECT * FROM dbo.tfnGetName()
With schemas. And no name ambiguity.
SELECT ScalarFN.GetName() FROM MyTable
SELECT * FROM TableFN.GetName()
Your "any other language" comment doesn't apply. SQL isn't structured like c#, Java, f#, Ada (OK, PL/SQL might be), VBA, whatever: there is no object or namespace hierarchy. No Object.DoStuff method stuff.
A prefix may be just the thing to keep you sane...
There's no need to prefix function names with fn_ any more than there's a need to prefix table names with t_ (a convention I have seen). This sort of systematic prefix tends to be used by people who are not yet comfortable with the language and who need the convention as an extra help to understanding the code.
Like all naming conventions, it hardly matters what the convention actually is. What really matter is to be consistent. So even if the convention is wrong, it is still important to stick to it for consistency. Yes, it may be argued that if the naming convention is wrong then it should be changed, but the effort implies a lot: rename all objects, change source code, all maintenance procedures, get the dev team committed to follow the new convention, have all the support and ops personnel follow the new rules etc etc. On a large org, the effort to change a well established naming convention is just simply overwhelming.
I don't know what your situation is, but you should consider carefully before proposing a naming convention change just for sake of 'pretty'. No matter how bad the existing naming convention in your org is, is far better to stick to it and keep the naming consistency than to ignore it and start your own.
Of course, more often than not, the naming convention is not only bad, is also not followed and names are inconsistent. In that case, sucks to be you...
What is a scenario that exemplifies a
good reason to use prefixes
THere is none. People do all kind of stuff because they always did so, and quite a number of bad habits are explained with ancient knowledge that is wrong for many years.
I'm not a fan of prefixes, but perhaps one advantage could be that these fn_ prefixes might make it easier to identify that a particular function is user-defined, rather than in-built.
We had many painful meetings at our company about this. IMO, we don't need prefixes on any object names. However, you could make an argument for putting them on views, if the name of the view might conflict with the underlying table name.
In any case, there is no SQL requirement that prefixes be used, and frankly, IMO, they have no real value.
As others have noticed, any scenario you define can easily be challenged, so there's no rule defining it as necessary; however, there's equally no rule saying it's unnecessary, either. Like all naming conventions, it's more important to have consistent usage rather than justification.
One (and the only) advantage I can think of is that it a consequently applied prefixing scheme could make using intellisense / autocomplete easier since related functionality is automagically grouped together.
Since I recently stumbled over this question, I'd like to add the following point in favour of prefixes: Imagine, you have some object id from some system table and you want to determine whether it's a function, proc, view etc. You could of course run a test for each type, it's much easier though to extract the prefix from the object name and then act upon that. This gets even easier when you use an underscore to separate the prefix from the name, e.g. usp_Foo instead of uspFoo. IMHO it's not just about stupid IDEs.
PostgreSQL has allowed me to name a column "campaign_$". I like the name because it's short and to the point, and other potential names like "campaign_receipts" seem longer and less clear.
BUT, I wonder if I'll eventually regret putting a $ symbol in a column name, either in PHP or in some other distant part of the architecture. Should I just stick to letters and underscores?
Thanks!
Yes, you should. "campaign_receipts" is a better name.
You probably won't regret, but I still wouldn't recommend it.
What happens when you expand into Europe?
Also, it will look strange and confusing to new developers.
In addition to the other excellent reasons I'll also mention that "$" in my mind is not clear at all. Does that mean campaign expenses? Campaign savings? Campaign values?
There's a VERY strong convention that tables and columns are named using only letters, numbers, and (possibly) underscores, so I would consider this poor style. Beyond the i18n concerns that other posters mention, there are probably a very large number of tools that expect table and column names following this convention.
I think it is bad practice to put special characters into a column name. Just spell out the word like campaign_money or campaign_funds and then the issue of internationalization or other possible issues become a thing of the past.
It should be fine, however it may cause you more problems down the line when you want to export the data to another system, things like that.
It's good to get into the habbit of naming columns/variables etc with no special characters, as usually they are more trouble than they are worth.
I wouldn't use it.
The "$" might not be valid in future databases you use (at some point you might migrate away from PostgreSQL to something else) and it also might pose problems at the application level if you do anything that maps column names to object properties if your programming language doesn't allow method names to have "$" in them.
Just my suggestion.
Are there any tools available for validating a database schema against a set of design rules, naming conventions, etc.
I'm not talking about comparing one database to another (as covered by this question).
I want to be able to say "What in this database doesn't meet this set of rules".
Some examples of the type of rules I'm talking about would be like:
- Primary key fields should be the first in the table.
- Foreign keys should have an index on that field.
- Field names ending 'xxx' should be of a certain type.
- Fields with a constraint limiting it it certain values it should have a default.
I've written a bunch of scripts to do this in the past and was wondering if there was something generic available.
Ideally I'd like something for SQL Server, but if you're aware of something for other databases it may be useful to know about them too.
One way to accomplish this would be to script out an entire database and then apply rules consisting of regular expressions to the script. SSW's commercial tool does something similiar for SQL Server.
A tool called SQLCop is doing what your asking for, but I don't believe it actually allows you to write rules yourself.
http://sqlcop.lessthandot.com/detectedissues.php
We are deciding the naming convention for tables, columns, procedures, etc. at our development team at work. The singular-plural table naming has already been decided, we are using singular. We are discussing whether to use a prefix for each table name or not. I would like to read suggestions about using a prefix or not, and why.
Does it provide any security at all (at least one more obstacle for a possible intruder)? I think it's generally more comfortable to name them with a prefix, in case we are using a table's name in the code, so to not confuse them with variables, attributes, etc. But I would like to read opinions from more experienced developers.
I find hungarian DB object prefixes to indicate their types rather annoying.
I've worked in places where every table name had to start with "tbl". In every case, the naming convention ended up eventually causing much pain when someone needed to make an otherwise minor change.
For example, if your convention is that tables start with "tbl" and views start with "v", thn what's the right thing to do when you decide to replace a table with some other things on the backend and provide a view for compatibility or even as the preferred interface? We ended up having views that started with "tbl".
I prefer prefixing tables and other database objects with a short name of the application or solution.
This helps in two potential situations which spring to mind:
You are less likely to get naming conflicts if you opt to use any third-party framework components which require tables in your application database (e.g. asp net membership provider).
If you are developing solutions for customers, they may be limited to a single database (especially if they are paying for external hosting), requiring them to store the database objects for multiple applications in a single database.
I don't see how any naming convention can improve security...
If an intruder have access to the database (with harmful permissions), they will certainly have permissions to list table names and select to see what they're used for.
But I think that truly confusing table names might indirectly worsen security.
It would make further development hard, thus reducing the chance security issues will be fixed, or it could even hide potential issues:
If a table named (for instance) 'sro235onsg43oij5' is full of randomly named coloumns with random strings and numbers, a new developer might just think it's random test data (unless he touches the code that interact with it), but if it was named 'userpasswords' or similar any developer who looks at the table would perhaps be shocked that the passwords is stored in plaintext.
Why not name the tables according to the guidelines you have in place for coding? Consider the table name a "class" and the columns a "property" or "field". This assists when using an ORM that can automatically infer table/column naming from class/member naming.
For instance, Castle ActiveRecord, declared like below assumes the names are the same as the member they are on.
[ActiveRecord]
public class Person
{
[PrimaryKey]
public Int32 Id { get; set; }
[Property]
public String Name { get; set; }
}
If you use SqlServer the good start would be to look at the sample databases provided for some guidance.
In the past, I've been opposed to using prefixes in table names and column names. However, when faced with the task of redesigning a system, having prefixes is invaluable for doing search and replace. For example, grepping for "tbl_product" will probably give you much more relevant results than grepping for "product".
If you're worried about mixing up your table names, employ a hungarian notation style system in your code. Perhaps "s" for string + "tn" for table name:
stnUsers = 'users';
stnPosts = 'posts';
Of course, the prefix is up to you, depending on how verbose you like your code... strtblUsers, strtblnmeUsers, thisisthenameofatableyouguysUsers...
Appending a prefix to table names does have some benefits, especially if you don't hardcode that prefix into the system, and allow it to change per installation. For one, you run less risk of conflicts with other components, as Ian said, and secondly, should you wish, you could have two or instances of your program running off the same database.