The purpose of this document is to establish standards by which current and future SQL databases, and applications
that access those databases, are designed. It is also a goal to ensure that all current and future development follows,
as closely as possible, standards put forth by IDEF1X (a standard written by the U.S. Air Force, and adopted by the
SQL Server user community). By following the standards presented here, it is hoped that consistency, reliability and
security can be more easily attained and maintained, and with it any “residual” benefits.
Before continuing the following assumptions are made. It is assumed that people working with SQL server as
Administrators or Developers will know how to identify objects in SQL Server, i.e. Devices, Databases, Tables, etc.
Based on this assumption words like “table”, “database”, “device” (or any abbreviations) will be omitted from
object names. It is also assumed that only the most experienced “users” will have access to SQL directly (through
apps. like Access, Excel, etc), and only to views or stored procedures expressly designed for non-standard usage. No
“users” will be permitted to change SQL objects nor modify data directly.
Following will be “object” specific standards. These standards are based primarily on information found in the book
“Designing Quality Databases with IDEF1X Information Models” by Thomas A. Bruce (published by Dorset House
Publishing) and the application ERwin version 2.6 by Logic Works. All object names will be in the singular form i.e.
a table for recording customer names would be labeled “customer_name”. Object names should be meaningful
and/or “intuitive”. If more than one word is used in an object name then underscores ( _ ) will be placed between
those words. It should be noted that the underscore must be used sparingly as this symbol counts as 3 characters. In
the example above “customer_name”, SQL treats the length of the complete name as 15 characters long, not 13.
Abbreviations and acronyms shall be used only where they are meaningful and are common knowledge. All names
will use lower-case except where noted. A table at the end provides examples of acceptable usage.
Server:
All servers will be named in accordance with current practice. Currently, a server name is made
up of 4 components. The first three characters signify the Group or Dept. the server services.
The next three characters represent the “function”. The next Alpha character represents the
succession with “A” being the first in line. The last character is the location. An example would
be “CCUSQLAC”. This server services the “CCU” group. The function is a SQL server. It is the
first in it’s order of succession and is located in the [C]omputer room (which is located in
building-E).
Backup Device:
Also know as a “dump” device. A more liberal approach may be used in naming backup devices
since a backup may be performed for a specific or singular purpose, such as a backup for a table
for a given day, like “accts_recvbl_7_21_1997”. In this example abbreviations are used due to
the limitation on the length of an object name, however, the abbreviations used are common
knowledge and intuitive, following guidlines proposed.
Database Device: Used for “data” or “log”, but not both, in other words a data device will not be used for both
“data” and “log”. If a server is used by two (or more) distinct or autonomous departments or
groups then it may be desirable to include that name, i.e. accounting_data1, legal_data1, etc.
Note: If a database is used for “Archival” purposes only it may be acceptable to permit log and
data to share the same device.
Database:
Should not include any form of the word “database” nor shall it be named after a group,
department, individual, etc. If more than one database exists on the same server and the
databases are to be kept distinct or autonomous, they must exist on seperate database devices.
Note: The same rule for Database Device may apply here for an “Archival” database.
Login:
The current environment supports Standard security where Login accounts are created on the
server and are exclusive to that server. Going forward Integrated Security will be used. In order
for existing systems to continue functioning servers will first be placed in Mixed Security mode.
When all databases on a server have been modified to use Integrated Security, the server may be
set to Intergrated Security Mode only, though this is not required. The source for all accounts
will be the NT Domain. This means that Group and User accounts will come from the NT
Domain (NT Network). These accounts will be used to grant permissions to servers, databases
and objects in those databases. This will assure consistency across all servers and databases.
Table:
Table names will be the only objects with all upper-case letters. As with other objects, table
names should not include any form of the word “table” and should follow the same “basic”
guidelines for naming objects.
Column:
Also referred to as “field name”, will follow the same guidelines as Table names except for
Case. It is expressly forbidden to use the word “name” by itself to identify a column name. If a
column holds data that could be separated into distinct parts, then individual columns should be
created to represent those parts. An example would be an individuals name which could be
represented with the following columns, “name_ first” and “name_ last”. Any time data can be
seperated into distinct columns for performance reasons, without degrading the usefulness of the
data, an extra effort should be made to apply this where logical and beneficial overall.
An exception to any of the above standards would be in the case of a third-party application which has a set schema
that can not be modified or altered without impacting it’s functionality.
Examples:
Usage
Database name
Table names
Device names
Column names
For reference purposes.
Inappropriate usage
MY_DATABASE
Appropriate usage
my_database
accounts_receivable
accounting
accounting_db
accounting
AccountsReceivable
ACCOUNTS_RECEIVABLE
ADDRESSES
BUSINESS_ADDRESS
general_ledger, payroll.
accounting_data1
backup, yesterdays_backup
accounting_data_backup,
accounting_backup_jan12
name_first, name_last,
company_name
date_start,date_end,
date_entered, date_closed
names
date
Notes
All objects to be in lower-case
except table names.
Accounts receivable is a part of
“accounting” and should be a
member of such a database.
The addition of _db provides no
“value” to the name and uses an
additional 5 characters.
Table names must be all uppercase and where more than one
word is used to form a name
underscores are to be used
between names.
Names are not to be plural. The
word “address” by itself is too
ambiguous.
Unless a database is autonomous
or distinct all related “objects
should reside within the same
device.
Names must be meaningful to be
of any benefit.
The word “names” is a reserved
word and is ambiguous.
The word “date” is a reserved
word and is ambiguous.
STORED PROCEDURES and VIEWS
Because Stored Procedures and Views vary widely in purpose, it is much harder to define standards, but an attempt
will be made here for “maintenance” reasons. All Views and Stored Procedures will be properly commented. At a
minimum the following areas will be identified, “Create date:”, “Created by:”, “Purpose:”, “Modified date:”, and
“Modified by:”. There will also be comments between batches (in stored procedures) to help identify what is taking
place (and where beneficial, why it’s taking place). For consistency, all comments will be identified using two
dashes, and the word comment in all upper-case letters, all starting at the left edge of the screen, Example...
--COMMENT
---COMMENT
Purpose:
Show proper usage of comments statement. If the text
will not fit on the same line, it should be “wrapped”
as follows. Tabs are used for alignment purposes.
Note: A tab is to be entered after the word comment and after the colon.
Also beneficial would be a list of any tables (and their respective databases) that are impacted by the process. This
becomes a benefit when planning modifications to tables which results in a need to identify what processes would be
impacted. Example...
--COMMENT
------COMMENT
Notes:
The following <database.table> will be affected.
database_1.table_2
database_2.table_4
database_2.table_5
database_3.table_1
database_4.table_1
A developer could glance at a list placed at the beginning of the view or stored procedure and very quickly determine
if that view or stored procedure would be impacted by any planned changes. This scenario is most likely to occur in a
situation where the procedure does not reside in one or more of the referenced datbases or where the System Stored
Procedure “sp_depends” is unable to identify foreign databases.