A Simple Database Naming Convention

In the early days of databases tooling was not able to interrogate the database. The result was that naming conventions where created that describe the functions of tables, views, fields and stored procedures. Today there are very good tools that allow these properties to be directly interrogated from the data access layer. Unfortunately these cryptic database naming conventions live on in many companies.

It is important that databases are built in a consistent way. Here is a brief database naming convention that allows a consistent design but without un necessary encryption.

1. Database Naming Convention

The following conventions are built from an extract of the naming conventions from Jason Mauss. The original can be found under the following link.

http://weblogs.asp.net/jamauss/articles/DatabaseNamingConventions.aspx

1.1 Tables

When naming your database tables, give consideration to other steps in the development process. Keep in mind you will most likely have to utilize the names you give your tables several times as part of other objects, for example, procedures, triggers or views may all contain references to the table name. You want to keep the name as simple and short as possible. Some systems enforce character limits on object names also. For example, in Oracle you are limited to about 30 characters per object.

Rules:

• Plural Names - Table names should be plural, for example, "Customers" instead of "Customer". For table names with multiple words, only the last word should be plural, for example, "UserRoles" and "UserRoleSettings".
• Prefixes - Used correctly, table prefixes can help you organize your tables into related groups or distinguish them from other unrelated tables. Used poorly, they can cause you to have to type a lot of unnecessary characters. We'll discuss what not to do first. Do not give your table names prefixes like "tbl" or "TBL_" as these are just redundant and unnecessary. Note that even for the prefix, use Pascal Case.
• Notation - For all parts of the table name, including prefixes, use Pascal Case.
• Special Characters
• For table names, underscores should not be used. The underscore character has a place in other object names but, not for tables.
• Do not use numbers in your table names either. This usually points to a poorly designed data model or irregularly partitioned tables.
• Do not use spaces in your table names either.
• If you are developing in a non-english language, do not use any of that language's special characters.
• Abbreviations - Avoid using abbreviations if possible. Use "Accounts" instead of "Accts" and "Hours" instead of "Hrs". Do not use acronyms.
• Junction a.k.a Intersection Tables - Junction tables, which handle many to many relationships, should be named by concatenating the names of the tables that have a one to many relationship with the junction table. For example, you might have "Doctors" and "Patients" tables. Since doctors can have many patients and patients can have many doctors (specialists) you need a table to hold the data for those relationships in a junction table. This table should be named DoctorsPatients". Since this convention can result in lengthy table names, abbreviations sometimes may be used at your discretion.

Example:

• Employees

1.2 Columns

(incl. PRIMARY, FOREIGN, AND COMPOSITE KEYS) - When naming your columns, keep in mind that they are members of the table, so they do not need the any mention of the table name in the name. The primary key field is typically the only exception to this rule where including the table name is justified so that you can have a more descriptive field name than just "Id". "CustomerId" is acceptable but not required. Just like with naming tables, avoid using abbreviations, acronyms or special characters. All column names should use Pascal Case to distinguish them from SQL keywords (all upper case).

Rules:

• Identity Primary Key Fields - For fields that are the primary key for a table and uniquely identify each record in the table, the name should simply be “Id“ since, that's what it is - an identification field. This name also maps more closely to a property name like “Id“ in your class libraries. Another benefit of this name is that for joins you will see something like
  "Customers JOIN Orders ON Customer.Id = Orders.CustomerId“
  which allows you to avoid the word “Customer“ again after the Customer table.
• Foreign Key Fields - Foreign key fields should have the exact same name as they do in the parent table where the field is the primary key - with one exception - the table name should be specified. For example, in the Customers table the primary key field might be "Id". In an Orders table where the customer id is kept, it would be "CustomerId". There is one exception to this rule, which is when you have more than one foreign key field per table referencing the same primary key field in another table. In this situation, it might be helpful to add a descriptor before the field name. An example of this is if you had an Address table. You might have another table with foreign key fields like HomeAddressId, WorkAddressId, MailingAddressId, or ShippingAddressId.
• Composite Keys - If you have tables with composite keys (more than one field makes up the unique value) then instead of just “Id“ you should use a descriptor before the “Id“ characters. Two fields like “ModuleId“ and “CodeId“ might make up the composite key, for example. If you don't see an “Id“ column in the table - you'll know that a composite key is used to uniquely identify records.
• Prefixes - Do not prefix your fields with "fld_" or "Col_" as it should be obvious in SQL statements which items are columns (before or after the FROM clause). Including a two or three character data type prefix for the field is optional and not recommended, for example, "IntCustomerId" for a numeric type or "VcName" for a varchar type. However, these data type abbreviations are DBMS specific and are outside the scope of this document.
• Data Type Specific Naming - Boolean fields should be given names like "IsDeleted", "HasPermission", or "IsValid" so that the meaning of the data in the field is not ambiguous. If the field holds date and/or time information, the word "Date" or "Time" should appear somewhere in the field name. It is sometimes appropriate to add the unit of time to the field name also, especially if the field holds data like whole numbers ("3" or "20"). Those fields should be named like "RuntimeHours" or "ScheduledMinutes".

1.3 Indexes

Since indexes are always related to a table or view, it makes the most sense to use the name of the table or view, as well as the column(s) they index, in the index name, along with some characters that specify the type of index it is. This naming convention also allows you, if looking at a list of indexes, to see the indexes ordered by table, then column, then index type.

Rules:

• Naming Convention - The naming convention for indexes follows this structure:
  {TableName}{ColumnsIndexed}{U/N}{C/N}
  where "U/N" is for unique or non-unique and "C/N" is for clustered or non-clustered. This naming convention is unique among database objects, so adding characters to denote it being an index, like "idx" is not necessary. The naming convention alone is self-documenting and indentifies it as an index. For indexes that span multiple columns, concatenate the column names. "ProductsIdUC" indicates a unique, clustered index on the Id column of the Products table. OrderDetailsOrderIdCustomerIdNN" indicates a non-unique, non-clustered index on the OrderId and CustomerId columns in the OrderDetails table. Since this name is rather lengthy with both "OrderId" and "CustomerId" spelled out, they could be shortened to OrdId and CustId. However, notice that by using Pascal Case, thus not needing to use underscores, it is possible to keep the name of a complex index to about 30 characters.
• Prefixes and Suffixes - Avoid putting a prefix like "idx" or "IDX_" before your indexes. This is not necessary due to the naming convention discussed in Rule 3a. A suffix of "_idx" or "IDX" is not necessary either for the same reason.

1.4 Constraints

Constraints are at the field/column level so the name of the field the constraint is on should be used in the name. The type of constraint (Check, Referential Integrity a.k.a Foreign Key, Primary Key, or Unique) should be noted also. Constraints are also unique to a particular table and field combination, so you should include the table name also to ensure unique constaint names across your set of database tables.

Rules:

• Naming Convention - The naming convention syntax for constraints looks like this:
  {constraint type}{table name}_{field name}
  Examples:
  1. PkProducts_Id - primary key constraint on the Id field of the Products table
  2. FkOrders_ProductId - foreign key constraint on the ProductId field in the Orders table
  3. CkCustomers_AccountRepId - check constraint on the AccountRepId field in the Customers table
• The reason underscores are used here with Pascal Case notation is so that the table name and field name are clearly separated. Without the underscore, it would become easy to get confused about where the table name stops and the field name starts.
• Prefixes - A two letter prefix gets applied to the constraint name depending on the type
  Primary Key: Pk
  Foreign Key: Fk
  Check: Ck
  Unique: Un

1.5 Views

Views follow many of the same rules that apply to naming tables. There are only two differences. If your view combines entities with a join condition or where clause, be sure to combine the names of the entities that are joined in the name of your view.

• Prefixes - While it is pointless to prefix tables, it can be helpful for views. Prefixing your views with "Vw" or "View" is a helpful reminder that you're dealing with a view, and not a table. Whatever type of prefix you choose to apply, use at least 2 letters and not just "V" because a prefix should use more more than one letter or its meaning can be ambiguous.
• View Types - Some views are simply tabular representations of one or more tables with a filter applied or because of security procedures (users given permissions on views instead of the underlying table(s) in some cases). Some views are used to generate report data with more specific values in the WHERE clause. Naming your views should be different depending on the type or purpose of the view. For simple views that just join one or more tables with no selection criteria, combine the names of the tables joined. For example, joining the "Customers" and "StatesAndProvinces" table to create a view of Customers and their respective geographical data should be given a name like "VwCustomersStatesAndProvinces". For a view that is more like a report, a name like "VwDivisionSalesFor2004" might make more sense.

1.6 Stored Procedures

Unlike a lot of the other database objects discussed here, stored procedures are not logically tied to any table or column. Typically though, stored procedures perform one of the CRUD (Create, Read, Update, and Delete) operations on a table, or another action of some kind. Since stored procedures always perform some type of operation, it makes sense to use a name that describes the operation they perform. Use a verb to describe the type of operation, followed by the table(s) the operations occur on.

• Prefixes or Suffixes - The way you name your stored procedures depends on how you want to group them within a listing. If you'd like to group them by the type of CRUD operation they perform, then prefix the name with "Create", "Get", "Update" or "Delete". Using this kind of prefix will, for example, group all of your "Create" procedures together since they will all start with the Create prefix, like "CreateProductInfo" or "CreateOrder". If instead, you would like to have your procedures ordered by the table they perform a CRUD operation on, adding "Create, Get, Update, or Delete" as a suffix will do that for you. For example, "ProductInfoCreate" or "OrdersCreate". If your procedure returns a scalar value, or performs an operation like validation, you should not use a CRUD prefix or suffix. Instead use the verb and noun combination. For example, "ValidateLogin"
• Grouping Prefixes - If you have many stored procedures, you might want to consider using a grouping prefix that can be used to identify which parts of an application the stored procedure is used by. For example, a "Prl" prefix for Payroll related procedures or a "Hr" prefix for Human Resources related procedures can be helpful. This prefix would come before a CRUD prefix (See Rul 6a).
• Bad Prefixes - Do not prefix your stored procedures with something that will cause the system to think it is a system procedure. For example, in SQL Server, if you start a procedure with "sp_", "xp_" or "dt_" it will cause SQL Server to check the master database for this procedure first, causing a performance hit. Spend a little time researching if any of the prefixes you are thinking of using are known by the system and avoid using them if they are.

1.6.1 Prefixes used in Project Datenmarkt

• User defined stored procedure are prefixed by “usp_”.

1.7 Triggers

Triggers have many things in common with stored procedures. However, triggers are different than stored procedures in two important ways. First, triggers don't exist on their own. They are dependant upon a table. So it is wise to include the name of this table in the trigger name. Second, triggers can only execute when either an Insert, Update, or Delete happens on one or more of the records in the table. So it also makes sense to include the type of action that will cause the trigger to execute.

• Prefixes and Suffixes - To distinguish triggers from other database objects, it is helpful to add "Trg" as a prefix or suffix. For example any of these combinations work: Trg_ProductsIns, ProductsInsTrg, Products_InsTrg, or InsProducts_Trg. As long as you include the table name, the operation that executes the trigger (Ins, Upd, or Del) and the "Trg" letters, it should be obvious to someone working with the database what kind of object it is. As with all conventions you use, pick one and remain consistent.
• Multiple Operations - If a trigger handles more than one operation (both INSERT and UPDATE for example) then include both operation abbreviations in your name. For example, "Products_InsUpdTrg" or "TrgProducts_UpdDel"
• Multiple Triggers - Some systems allow multiple triggers per operation per table. In this case, you should make sure the names of these triggers are easy to distinguish between. For example "Users_ValidateEmailAddress_InsTrg" and "Users_MakeActionEntries_InsTrg".