Marcello,
Not a big surprise as naming conventions have a lot to do with
personal prefernces. There are a lot of threads in comp.databases and
the other database groups. Just do a search for "naming conventions"
in the groups.
In my oppinion one of the good conventions is presented by Joe Celko
in "SQL Programming Style". I would suggest reading it and pick up
what makes sense to you and alter what you do not like at all. Reading
other oppinions is also a good way to come up with your own
conventions even if you think they are crazy. The key is to be
consistent and that your colleagues in your group are also willing/
able to adapt your convention.
Some namings also have to do with the environment you are using. For
example PascalCase works fine with SQL Server and looks nice, but in
IBM DB2 everything will be uppercased, and then the good readability
is lost. If you plan to move to such a system or would like to ensure
portability, underscore conventions are better.
I would name a column after what it contains and not where it resides.
E. g. I choose "ProductNam e" not because the table is named
"Products", but because the column contains the name of a product.
If you name your columns so that no two columns have the same name,
where in fact they contain differenct things ("ProductNam e" and
"CompanyNam e" and not just "Name" what is too vague) this problem does
not occurr; then you can avoid alias names in most cases. Also I do
not assign "ID" to a tables primary key, but choose appropriate names
such as "ProductID" , "CompanyID" , etc. If you could find some real key
(what is the better choice) for the table it might get something else,
such as "ContainerNumbe r" to identify shipping containers, what is an
industry standard and ensures uniqueness worldwide (http://
en.wikipedia.or g/wiki/ISO_6346). In this example it would not make
sense at all to say "ContainerI D" and give it and IDENTITY auto-value
or something like that.
brgds
Philipp Post
I spent my whole Sunday reading database naming conventions,. And this only made me more confused. <
personal prefernces. There are a lot of threads in comp.databases and
the other database groups. Just do a search for "naming conventions"
in the groups.
In my oppinion one of the good conventions is presented by Joe Celko
in "SQL Programming Style". I would suggest reading it and pick up
what makes sense to you and alter what you do not like at all. Reading
other oppinions is also a good way to come up with your own
conventions even if you think they are crazy. The key is to be
consistent and that your colleagues in your group are also willing/
able to adapt your convention.
Some namings also have to do with the environment you are using. For
example PascalCase works fine with SQL Server and looks nice, but in
IBM DB2 everything will be uppercased, and then the good readability
is lost. If you plan to move to such a system or would like to ensure
portability, underscore conventions are better.
I allways prefix the column name with a prefix that identifies the table where It resides. <
E. g. I choose "ProductNam e" not because the table is named
"Products", but because the column contains the name of a product.
So what is the advantage if I would have to give a an alias for the Name Fields? <
where in fact they contain differenct things ("ProductNam e" and
"CompanyNam e" and not just "Name" what is too vague) this problem does
not occurr; then you can avoid alias names in most cases. Also I do
not assign "ID" to a tables primary key, but choose appropriate names
such as "ProductID" , "CompanyID" , etc. If you could find some real key
(what is the better choice) for the table it might get something else,
such as "ContainerNumbe r" to identify shipping containers, what is an
industry standard and ensures uniqueness worldwide (http://
en.wikipedia.or g/wiki/ISO_6346). In this example it would not make
sense at all to say "ContainerI D" and give it and IDENTITY auto-value
or something like that.
brgds
Philipp Post
Comment