Re: Database naming conventions?

Re: Database naming conventions?

On 23 jun, 06:43, Philipp Post <Post.Phil...@g ooglemail.comwr ote:

Marcello,

In my oppinion one of the goodconventions 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 ownconventionse ven 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.

If I´m not wrong he prefixes too.

>
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, underscoreconve ntionsare better.
>

I didn´t know that ,Thanks.

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. etc.

So you´re prefixing it anyway,Sometime s with the whole table name,but
not for every field.

I´m also participating in this thread,explaini ng why I decided to
prefix,and Why I´m not sure if it is good or not.

http://groups.google.com.br/group/borland.public.delphi.database.general/browse_thread/thread/3b316bf204278e5f/b47fa7b7fe497fcc?hl=pt-BR&lnk=st&q=database+naming+conventions#b47fa7b7fe497fcc

Thanks,
Marcello

Marcello,

I spent my whole Sunday reading database naming conventions,. And this only made me more confused. <

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 allways prefix the column name with a prefix that identifies the table where It resides. <

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.

So what is the advantage if I would have to give a an alias for the Name Fields? <

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