A Naming Scheme for Database Tables and Fields
Database developers have historically used a somewhat cryptic system for naming database tables and fields. Originally a result of the limitations of database management systems (DBMS), these naming schemes - or the lack thereof - have been adopted by convention and tradition. However, as database applications become more complex, with more tables and larger teams of developers, and as developers come and go, it becomes much more important to implement a robust and disciplined naming scheme for database objects. A well-defined naming scheme becomes more important when you adopt object relational mapping (ORM) technologies or automatic code generation.
This article presents one scheme that has worked for me for years in multiple successful commercial applications.
Perhaps the most common practice in database naming is to use all one case (upper or lower) with words separated by underscores, and heavily abbreviated. Fixed case names have become the standard because database systems are traditional case-insensitive in table and field names (or required fixed case). It is also a holdover from academia where use of a single case is common not just in database design, but in programming languages (for example, C language is traditionally taught in lower case and FORTRAN in upper case). Separating words with underscores is a natural result of fixed case names and also is commonplace in academia. The heavy use of abbreviations is a holdover from the days of dBase and other systems where there was a stringent limit on table and field name lengths. Many database designers schooled in the older systems still retain this use of abbreviated names in a severe case of the psychological principle of learned helplessness.