Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

❑ When building tables based on other tables (usually called linking or associate tables), you
should include the names of all parent tables in your new table name. For example, say you have
a movie database where many stars can appear in many movies. If you have a Movies table
and a Stars table, you may want to tie them together using a table called MovieStars.
❑ When you have two words in the name, do not use any separators (run the words together) —
use the fact that you capitalize the first letter of each new word to figure out how to separate words.
I can’t begin to tell you the battles I’ve had with other database people about naming issues. For example,
you will find that a good many people believe that you should separate the words in your names with an
underscore (_).Why don’t I do it that way? Well, it’s an ease of use issue. Underscores present a couple of
different problems:
❑ First, many people have a difficult time typing an underscore without taking their hand away
from the proper keyboard position — this leads to lots of typos.
❑ Second, in documentation it is not uncommon to run into situations where the table or column
name is underlined. Underscores are, depending on the font, impossible to see when the text is
underlined — this leads to confusion and more errors.
❑ Finally (and this is a nit pick), it’s just more typing.
You also have the option to separate the words in the name using a regular space. If you recall my very
first soapbox diatribe back in Chapter 1, you’ll know that isn’t really much of an option — it is
extremely bad practice and creates an unbelievable number of errors. It was added to facilitate Access
upsizing, and I continue to curse the person(s) who decided to put it in — I’m sure they were wellmeaning,
but they are now part of the cause of much grief in the database world.
This list is certainly not set in stone; rather it is just a Reader’s Digest version of the rules I use when
naming tables. I find that they save me a great deal of grief. I hope they’ll do the same for you.
Data Types
Chapter 5: Creating and Altering Tables
Consistency, consistency, consistency. Every time I teach, I always warn my class
that it’s a word I’m going to repeat over and over, and in no place is it more important
than in naming. If you have to pick one rule to follow, then pick a rule that says
that, whatever your standards are — make them just that: standard. If you decide
to abbreviate for some reason, then abbreviate that word every time (the same way).
Regardless of what you’re doing in your naming, make it apply to the entire database
consistently — consider having a standards document or style guide to make
sure other developers utilize the same rules you do. This will save a ton of mistakes,
and it will save your users time in terms of how long it takes for them to get to know
the database.
There isn’t much to this — the data types are as I described them in Chapter 2. You just need to provide
a data type immediately following the column name — there is no default data type.
125