Database Reference
In-Depth Information
Keep the Names Short
In our opinion, too many people abuse the ability to give things longer
names these days. This isn't limited to databases by any stretch. In
Windows, files can have extremely long names, and SQL Server is no dif-
ferent. A short but descriptive name is always a better alternative to a long,
more human-readable name. Long names don't cause syntax problems, but
they cause frustration and can cause developers to write some ugly-looking
code. Imagine a database where stored procedures have names such as
proc_select_all_customer_data_by_company_grouped_by_month.
Although this doesn't break any of our other rules—no spaces or dashes,
and no keywords—it is a little long to deal with. Imagine trying to type that
in each script you write. It would be time consuming, not to mention caus-
ing great difficulty in locating a typo if one should occur. Now imagine a
whole script filled with table and view names similar to this one. It is
always best to keep it short. In this case, a name like proc_monthly
_custdata_by_company, though still a little long, would be a much better
alternative.
In addition to being short, the name should be descriptive. Don't go
too far to the other extreme and start calling views something like mtcusdat.
This name could mean almost anything. Make sure you follow both aspects
of this rule: short and simple, but long enough to have meaning.
Using Case in Your Names
Here is where we receive the fan mail and the hate mail all in one section
of the topic. When it comes to using case, we feel that the best option is to
keep
everything
in your database in lowercase. This means it is more diffi-
cult to separate two words in an object, so we use underscore characters
between them.
Now, we agree that a name like TblActiveCustomers is a lot nicer to
look at than tbl_active_customers, but there is a specific reason we prefer
the latter. It all goes back to case sensitivity, as we mentioned earlier. If you
are enforcing good standards in your database and in your code, all refer-
ences to database objects should match the case of the object name. The
problem is that so many SQL Servers are set up to be case insensitive that
it makes it easy to get lazy. With a name like TblActiveCustomer, it's too
easy to reference it in the code as tblActiveCustomer or tblactivecustomer.
This is all fine and good on a case-insensitive box, but if the database is
placed on a case-sensitive server then all the code will need to be fixed. If
everything is always in lowercase, it's a lot easier to remember the standard.
Search WWH ::
Custom Search