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:
AddTabSetupTabBasedOnSourceFileCreateTabBasedOnSourceFileDoIt
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.
