Database Reference
In-Depth Information
you do for tables, so it's helpful to know quickly which type of object you
are accessing.
Second, naming standards can prevent problems that can arise because
of your SQL Server configuration. This comes into play most often in case
sensitivity. If you name your objects in a standardized way, then your code
can be written in the same way. This match of code to object name is cru-
cial if you are going to host your database on a case-sensitive server. If you
refer to a table in code as Employee and the table is actually named em-
ployee, a case-sensitive server will tell you the table doesn't exist.
“OK,” you might be saying, “I'll just set up my SQL Server to be case
insensitive.” But what if that decision is taken away from you, now or five
years from now? There is nothing worse than going back over old code to
make sure that the case matches the table because your customer decided
it needed case sensitivity. Using good naming standards now prevents you
from having to do more work later.
Finally, naming standards can help force good standards on the data-
base developers. We have worked with some extremely talented develop-
ers, but talent in C# does not always translate to talent in T-SQL.
Developing for databases is a whole different animal, so anything you can
do to enforce better standards will be a big help.
As we said, there is no right or wrong method for your database nam-
ing standards. No matter which standard you implement, the point is that
you have one. To see whether your standard is a good one, ask yourself a
few questions.
Does the naming standard make sense to you?
You need to make sure that the standard makes sense to you and that
you will be able to follow it during your design. If the standard con-
tains hard-to-use or hard-to-remember elements, then you will likely
forget about them and end up deviating from your own standard.
Will others understand the standard?
Your standard must also make sense to others. If it doesn't make
sense to the other people who will be using it, then they too may for-
get parts of the standard. Make sure you run your thinking by a col-
league before the standard gets etched in stone.
Does the standard lend itself to consistency?
Can you implement your standard the same way over and over
again? As we mentioned earlier, complex elements make for a
difficult-to-implement standard. Just remember to keep it simple.
Search WWH ::




Custom Search