Re: Database naming convention (yet another post of it, but a bit different)

>> ... to propose my own naming convention and to see if someone can
point out some concept errors or may be propose some rules I didn't. <<

Use the ISO 11179 Metadata Standards for naming data elements instead of inventing your own.

>> 1) tables names are in singular .. <<

No. A table is a set of entities. A singular name is bad; a plural name is better; a collective noun is best. Example:  

 Employee = bad
 Employees = better
 Personnel = best

 Tree = bad
 Trees = better
 Forrest = best

>> 2) tables and field [sic] names are all lower-case, .. <<

I use lowercase for scalar values, like declared variables and column names, capitalize table and other schema object names and upper case the keywords. Proper nouns are capitalized in English (and German and most Europena languages). Upper case keywords are easier to see in the text. All lowercase is a blur,

>> 3) When using a foreign key, I use as the field [sic] name, the
same name of
the table that the foreign key is pointing to. <<

No. An attribute is named for what is MEANS, not for where is it located, not for how you are using this time. Does an apple become a hammer if you put it in a tool box?

Never use names like "id" or "date" or "value" -- you have to ask "id of what?", "date of what?" and "value of what??"

If there is an industry standard code, alway use it. For example, instead of calling something "id" or "product_code", use UPC or EAN.

>> ... using the same naming convention as for object programming ...
<<

Very bad idea. Bjarne Stroustrup spoke to the ANSI X3H2 Database Standards Committee about OO and databases many years ago. I agree with him that they have nothing to do with each other and that OO in a database is a REALLY BAD idea.

>> 4) Use underscore to replace spaces. <<

Yes. This means you can use the smae names in the SQL and in the host language program.

>> 5) Do not abbreviate! <<

Yes. But allow for only common abbreviations or those used in the trade. Every American knows "ssn" is "Social Security Number", every Canadian knows "sin" is "Social Insurance Number", etc.

>> 6) Do not try to use prefixes refering to data types, or
identifying
fields, tables, etc. <<

Yes.

>> 7) Do not repeat the table name in a field's [sic] name ... <<

Only if the column represents something that is logically different and that is the best name for it. Is an employee_id different from a client_id? Probably.
But an employee_name and a client_name are probably drawn from the same domain, checked by the same rules, etc.

>> PS: Excuse my English. me not speak too good <<

That is okay; my "any-language-but-English" does not exist! Received on Wed Oct 09 2002 - 18:13:29 CDT