Click here to Skip to main content
11,635,656 members (79,479 online)
Click here to Skip to main content

Database naming conventions

, 14 May 2011 CPOL 10.9K 2
Rate this:
Please Sign up or sign in to vote.
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.

License

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

Share

About the Author

Andrew Zwicker
United States United States
No Biography provided

You may also be interested in...

Comments and Discussions

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

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

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

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.150728.1 | Last Updated 14 May 2011
Article Copyright 2011 by Andrew Zwicker
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid