Database Reference
In-Depth Information
Choosing good names for database objects
The easiest way to help other people understand a database is to make sure that all the
objects have a meaningful name.
What makes a meaningful name?
How to do it...
F
The name follows the existing standards and practices in place. Inventing new
standards isn't helpful; enforcing existing ones is.
F
The name clearly describes the role or table contents.
F
For major tables use short, powerful names.
F
For lookup tables, name them after the table to which they are linked, such as
account_status.
F
For associative or linked tables, use all of the names of the major tables to which
they relate, such as customer_account.
F
Make sure that the name is clearly distinct from other similar names.
F
Use consistent abbreviations.
F
Use underscores. Case is not preserved by default, so using camelCase names, such
as customerAccount, as used in Java will just leave them unreadable. See recipe on
handling objects with quoted names..
F
Use consistent plurals, or not.
F
Use suffixes to identify the content type/domain of object. PostgreSQL already uses
suffixes for automatically generated objects.
F
Think ahead. Don't pick names that refer to the current role or location of an object.
So don't name a table "London" because it exists on a server in London. That server
might get moved to L.A.
F
Think ahead. Don't pick names that imply that this is the only one of its kind, such as
a table named TEST, or a table named BACKUP_DATA.
F
Avoid using acronyms in place of long table names. For example, money_allocation_
decision is much better than MAD. This is especially important when PostgreSQL
translates the names to lower case, so the fact that it is an acronym may not be clear.
F
The tablename is commonly used as the root for other objects that are created,
so don't add the suffix "table" or similar ideas.
