It has been said that the two hardest problems in IT are caching, and naming things. When it comes to databases naming conventions. – extra care must be taken. Naming database tables, procedures and views consistently not only makes it easier to write auto generated code, it also helps relieve mental strain on the consumers of the database. While it may seem like a trivial amount of effort to code of query against a poorly, or inconsistently named schema – the amount of time you spend cursing over inconsistencies add up. This is time that is hard to quantify, because it is spread even over everyone that touches the database. Because the time is hard to quantify, the small effort required to eliminate it completely is often ignore. This is why it is important to establish a database naming convention early in every project.
Because database naming conventions are so important, I have started an initiative to maintain naming conventions for different database types. A single system will not fit everyone and there is a great amount of personal test involved. Because of this, I will be building varying conventions that fit different purposes. The things that are general, I will keep together.
Below are the current conventions I am working on:
- General Conventions – Rules that apply to every database
- Data Warehouse Conventions – Rules specific to data warehouses and BI systems
- OLTP Conventions – Not yet ready, naming conventions for OLTP systems.
For every article here, I will try to balance out the arguments for and against each choice of naming. This gives consumers of this site a single place to keep track of the argumentation. If you have additions, please help me out by commenting on each page.
Conventions used in the Conventions
To make browsing easier, I have used the following rendering techniques.
Rules are written like this
Rejected alternative rules are written like this
The reason the rule has been rejected will be described under each rejected rule