Allen said:
Indeed. This area warrants a whole book. Happily there is such a book.
Joe Celko defends his own convention in his SQL Programming Style book,
both of which I use and recommend.
It is primarily based on readability e.g. keywords in upper case (e.g.
SELECT), table names in Pascal case (e.g. BudgetPeriod) and column
names in lowercase with each word separated by an underscore (e.g.
last_name).
Formatting aside, it is based on ISO 11179-5 naming conventions, The
ISO standard is more flexible because it uses Pascal case *and*
underscores e.g. contrast:
Cost_BudgetPeriod_TotalAmount (ISO)
cost_budget_period_total_amount (Celko)
The ISO convention makes it easier to pick out the class name,
qualifier term, etc, which is great for a data dictionary. For SQL
code, contrast:
SELECT C1.budget_period_total_amount FROM CostAnalysis AS C1 (ISO)
SELECT C1.BudgetPeriod_TotalAmount FROM CostAnalysis AS C1 (Celko)
The Celko convention makes it easier to spot the table name among the
columns
One point that is often overlooked is that the naming convention should
be consistently applied throughout the data model. This does not
necessarily mean that the name does not change e.g. the column may be
named 'last_name' in the Customers (pluralized because it is a
collection of customers) table but would be named customer_last_name in
the OrderDetails resultset.
To help with consistency, a data dictionary is almost essential i.e.
one that aids the design of the schema (rather than a 'picture' of the
schema after the event).
I recall someone suggesting the data dictionary hold a three character
correlation name (alias) for each table in the schema, with the aim of
greater consistency. A bit strict but does strike me as a good idea
worth repeating.
As for whether table prefixes based on physical characteristic or
Access UI tab (tbl, qry, vw, etc) are recommended, see the recent
discussion:
http://groups.google.com/group/micr..._frm/thread/c1c5bf9360c36749/c4415d1ac8f81278
The thread also touches on the motivation for having a convention. My
motivation is to make my SQL code easy to maintain by both me, my
colleagues and the poor sod who inherits it when I'm gone.
Jamie.
--