Notice anything?
swynk@sswug.org < Let me know what you think!
Thoughts for Database Naming Conventions
Today I have lots of food for thought when it comes to naming things in the Database. The meaning of data as well as the name of the data are frequent questions that have been asked. Some feel that meaning is more important than naming conventions? Are these two goals really mutually exclusive? Is it not possible to have a naming convention that is both meaningful and standardized?
For example, what about having a different name for columns contained in a summary table (probably a data mart or view) than the name used for an individual value. Let’s say we have a database of telephone calls. In the detail table where each call is broken out we may have a column named Duration. IMHO, using Duration in a monthly summary table or view as the column name may be confusing. Perhaps it may be more meaningful to have the detail table name the column CallDuration, and the summary table, call the rolled up column MonthlyDurationSum.
Then there is no confusion as to the true meaning of the data. I haven’t used this methodology myself. But I thought it worth bringing up for scrutiny.
Dan Writes:
As an Oracle and Microsoft Certified DBA with over 20 years exp., I cringe most of the time coming in after others to clean up failed projects. Naming standards is by far the worst offender for these project failures causing confusion and lack of a common vocabulary when communicating data elements.
It saddens me to see the type prefix used with Microsoft based implementations. I gag when I see tbl_*, vw_*, fn_*, and the worst sp_* (which of course should never be used). This immediately alerts me that the mess will be more extreme due to the lack of experience that created these objects. E.F. Codd would have the same reaction as Bjarne Stroustrup when discussing Hungarian Notation if he could see this today.
I am a fan of Pascal Naming with Database objects. It should not matter if “GetPatientFirstName” is a function (scalar or table) or a procedure. As a profession, I should be able to find this using the database schema catalog easily. Table objects using Pascal long names are easily communicated through all project members (including stakeholders) with much more grace and ease than others.
Just my $0.02
John reminds us that naming is not the only important thing when it comes to data:
Not to decrease the value of Object Naming Conventions, I find that access to a clear definition of object to be more important than the name of the object. If that definition is encapsulated in the object name so much the better. The greater value is in documentation of the meaning of the object.
Andrea says:
Using meaningful names is a good thing, but many times even a long name isn’t enough to describe the real content of a database field, so the only solution is to write several lines of text in the field definition (using the modeling tool).
Plus, delivering meaningful information and having a standardized name format unfortunately have contrasting requirements.
Do you have any opinions struggling to get out? Then let them go by sending me an Email at btaylor@sswug.org.
Cheers,
Ben