Click here to Skip to main content
16,016,022 members
Articles / All Topics

Database naming conventions

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
14 May 2011CPOL2 min read 42.8K   3   1
Having clear, concise names for tables, procedures, etc., is important for many reasons.

Naming conventions are important in a database and in application development in general. Having clear, concise names for tables, procedures, etc., is important for many reasons. It makes searching for the relevant procedure/table easier. It is more intuitive for someone learning the system. It helps keep your database from becoming an unmaintainable mess.

For example, let’s consider the Stored Procedure mentioned in a previous post that takes the source code file name and the tab name as inputs and inserts the necessary records to generate a new tab on the MyBPS website. Here are some potential names:

  1. AddTab
  2. SetupTabBasedOnSourceFile
  3. CreateTabBasedOnSourceFile
  4. DoIt

The fourth one is somewhat of a joke, although undoubtedly there are some developers out there who use naming conventions like this just for kicks. While it might seem funny at the time, it won’t help the next person in tracking down the procedure.

As for the more legitimate options, AddTab is accurate in terms of the end result, but it misses a major component of what the procedure does – using the source code file as the starting point. As for the other two options, I consider CreateTabBasedOnSourceFile to be the preferred name – ‘Create’ is one of the standard CRUD operations and is a more standard term than ‘Setup’ in database terminology.

In general, the goal is self-documenting names. When I see the name CreateTabBasedOnSourceFile, I don’t have to guess what’s going to happen when I run the procedure. If I didn’t know what procedure accomplished this task, it wouldn’t take me long to find it. From a naming convention standpoint, being somewhat verbose is better than being too terse.

Also, consistency in naming is highly important. Even if self-documenting names are used, if different procedures are named with different essentially equivalent words ['Create', 'Setup', 'Generate', 'Insert', 'Make', 'Produce', etc.], the database will simply become less maintainable.

At Boston Public Schools, our main school table suffers from being poorly named – it has an embedded year in the table name. It is likely this was done with the intention that a new version of the table would be created each school year. The problem is that so many systems began to depend on this table name that it has remained unchanged for over a decade now. This might not be a problem except for the fact that new members of the development group [not privy to this table] would probably mistake it for a historical backup.

If poor naming conventions are frequent, it can lead to a mess when trying to track down a certain procedure/table or expand on the system. So the solution is: before running that Create Table or Create Procedure script, check the name to ensure it makes sense, is self-documenting, and is consistent with other names in the database.

This article was originally posted at http://www.helpwithsql.com?p=29

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
United States United States
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
General...been there Pin
dmjm-h17-May-11 5:48
dmjm-h17-May-11 5:48 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.