SQL Server naming conventions
Rob Campbell-White
conventions.
They want to prefix what they are calling lookup tables with the characters
'LU' on the basis that it makes lookup tables easier to recognise.
Easier to recognise? So what! It's practical application that matters more
to me - when I'm writing queries and joins I don't care where the table
sorts alphabetically in Enterprise Manager!
My argument is that a table is a table regardless of what it contains. If
you're going to apply prefixes to lookup tables then you should apply
prefixes to every type of table. It all ends up being redundant. How are
you supposed to remember which tables are lookup tables prefixed with LU
when you're writing queries? If you name all tables according to their
contents and only their contents then there's no confusion about which
prefix to apply. Furthermore, what really is the definition of a lookup
table?
My standard of naming tables without prefixes, naming primary keys after the
table and suffixing the letters ID would allow everyone to write queries
without worrying whether the table they are querying or joining to should be
prefixed with 'LU'.
Aaaaarrrrgh! Any views out there on this?
Rob
Rick Razzano
consistent across databases. Prefixing is a convention not to make things
more complex, but to reduce complexity. I don't know how many tables are in
your database, but the more you have, the harder it is to keep all those
tables and their relationships in your mind at one time. A good naming
convention can reduce the complexity by grouping tables by modules. In
addition, a good naming convention can actually make it easier to remember
names, since they follow a consistent standard. For instance, you might
have a database with the following modules:
customers -- prefix 'cust_'
orders -- prefix 'ord_'
items -- prefix 'item_'
accounts -- prefix 'acct_'
Customer tables:
cust_master
cust_address
cust_ord_rel
cust_type
Order tables:
ord_master
ord_item_rel
ord_item_type
Account tables:
acct_master
acct_cust_rel
acct_invoice
acct_invoice_ord_rel
acct_payment
acct_type
It's a pretty trivial case, but the point is that the naming convention
standardizes the way names are created. The ideal would be that if you are
not exactly sure of the name of a table, you could figure it out just based
on the the table's function. Again, this seems easy to you, but when you
are going in to work on someone else's database, a poorly-standardized
naming system, frankly, sucks. You have to keep looking up table names
because every table was named differently. Some are plural. Some are not.
Some use underscores (customer_orders), some use embedded capitals
(customerOrders). Some put the module first, some last. Some have
prefixes, some suffixes, some both, some none. But when you have a good
naming convention, you really just need to know the "rules" of the
convention, and most of the table names will be easy to remember/figure out
on the fly, because they make sense.
I personally think that prefixes are usually helpful. They're not necessary
of course, but they often make the job of creating a standard convention
easier. You can use your convention of 'name all tables according to their
contents and only their contents,' but take into consideration others that
are using the database, and that what makes sense to you may seem like a
very random method to others.
Rob Campbell-White wrote in message ...
nsc
except we call them validation tables and prefix them with "val_". I think
from the application development (especially initial development) it
probably is not necessary since you are very familiar with the database but
when wrtiing adhoc queries or when not familiar with a particular database
struture I think it helps since these so called lookup/validation may
oftern have very similar names to the table they are foriegn keyed for
lookup/validation.
Tim
"Rob Campbell-White" <r...@clubconnexion.com> wrote in message
news:e7LgfQ9UAHA.243@cppssbbsa03...