MS SQL Server - Database Naming Convention

Author

Database Naming Convention - Sanity Check

Jerry Spivey

2006-02-06, 8:23 pm

Hi,

I've been putting together a database naming convention standard for our SQL
developers the last couple of days. I've chosen a more verbose standard to
help reign in my developers and to help improve the documentation, use and
understanding of their T-SQL code. I've looked over it a few times but it
is all starting to look the same to me ;-) If anyone is interested in
providing me with a sanity check for the document and provide "useful"
feedback without slamming criticism I'd appreciate it. Again, the
verboseness of the standard is by design.

Thanks all.

Jerry

SQL Server

Database Naming Conventions

Purpose

The purpose of creating and adopting a standardized database naming
convention is to ensure that all database objects and/or their purpose or
function is easily identifiable and understandable to all parties who create
and/or reference these objects in application code and reports. "Consistent
use" is the key to the success of a standardized database naming convention.
This database naming convention is designed to be more verbose to facilitate
self-documentation and to improve code understanding.

General Naming Guidelines for all Database Objects

a.. Use an object name that is easily understandable (short and
meaningful)
b.. Use an object name that easily identifies the purpose or functionality
of the object
c.. Use prefixes instead of suffixes to identify the type of object
d.. Limit the number of characters in each object name (< 30 characters
whenever possible)
e.. Limit the use of numbers in object names (use only letters and
underscores whenever possible)
f.. Use a character for the first letter in an object name
g.. Limit the use of underscores in object names (use Pascal case notation
for the object name following the application and object type identifiers)
h.. Avoid using abbreviations in object names
i.. Avoid using acronyms in object names
j.. Avoid using T-SQL special meaning characters i.e., @, %, #, ##
k.. Do not use spaces in object names
l.. Do not use hyphens (dashes) in object names
m.. Do not use any SQL Server or ODBC reserved keywords in object names
(see SQL Server Books Online for a complete listing)
n.. Ensure the dbo user is the owner of all database objects; always
prefix the object name with dbo
a.. Example: CREATE TABLE dbo.DM_tbl_Employees

Object Types

1.. Databases
2.. Tables
3.. Columns
4.. Constraints
5.. Indexes
6.. Triggers
7.. Stored Procedures
8.. Views
9.. User-defined Functions
10.. User-defined Data Types
11.. Defaults and Rules
12.. Variables and Parameters

1.. Databases
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Ensure the database name chosen easily identifies the purpose,
function, application or department for which the database will be used

2.. Tables
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Use prefixes instead of suffixes in identifying tables. The
exception to this rule is when a table is being partitioned into multiple
parts i.e., year. In this case, _year can be appended to the table names to
differentiate the tables i.e., DM_tbl_Sales_1995.

· Each table should begin with a capitalized 2 to 3 letter
combination prefix (with underscore) that uniquely identifies the
application to which the table belongs i.e., Dataminer = DM_, Electronic
Service Report = ESR_

· Following the application identifier, each table should have a
tbl_ entry to identify the object as a table

· Following the application and table identifiers, each table should
have a 1 to 3 word name that identifies the contents of the table. Plural
names should be used i.e., Customers instead of Customer

· Examples:

o The customers table for the Data Miner application would be named:
DM_tbl_Customers

o The scanned invoices table for the Electronic Service Report
application would be named: ESR_tbl_ScannedInvoi
ces

3.. Columns
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Each column should have a 1 to 3 word name

· The table name should not be included in the column name with the
exception of the ID (or PK) column for the table i.e., CustomerID

· The join column between tables should have the same name

· Boolean columns should be prefixed with a "Is" or "Has" i.e.,
IsApproved (0 = NO/FALSE; 1= YES/TRUE )

· The column name should not include the data type (or abbreviation)
of the column

· Always include NULL or NOT NULL for each column defined

4.. Constraints
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Each constraint should be given a user-defined name instead of the
system supplied name

· Each constraint should have a capitalized two letter combination
prefix (with underscore) that identifies the type of constraint: PRIMARY
KEY = PK_, FOREIGN KEY = FK_, UNIQUE = UC, CHECK = CK, DEFAULT = DF

· By default when a PRIMARY KEY constraint is created a clustered
index is created behind-the-scenes to support the constraint functionality.
For clustered PRIMARY KEY constraints, append CL_ to the object name and for
non-clustered PRIMARY KEY constraints append NC_ to the object name

· By default when a UNIQUE constraint is created a non-clustered
index is created behind-the-scenes to support the constraint functionality.
For clustered UNIQUE constraints, append CL_ to the object name and for
non-clustered UNIQUE constraints append NC_ to the object name

· Following the constraint identifier prefix, the table name (with
underscore) should be appended

· Following the table name, the column(s) to which the constraint
applies should be appended (separated with underscores for multiple columns
if needed)

· For FOREIGN KEY constraints, the table name and column from both
the referenced (parent) table and the child (referencing) table should be
included i.e, parent_parentcolumn_
child_childcolumn (parent listed first)

· Examples:

o A PRIMARY KEY constraint (clustered index) on the CustomerID column
in the Customers table would be named: PK_CL_Customers_Cust
omerID

o A PRIMARY KEY constraint (non-clustered index) on the CustomerID
column in the Customers table would be named: PK_NC_Customers_Cust
omerID

o A UNIQUE constraint (clustered index) on the SecurityNumber column
in the Customers table would be named: UC_CL_Customers_Secu
rityNumber

o A UNIQUE constraint (non-clustered index) on the SecurityNumber
column in the Customers table would be named:
UC_NC_Customers_Secu
rityNumber

o A UNIQUE constraint (clustered index) on the SecurityNumber and
Type columns in the Customers table would be named:
UC_CL_Customers_Secu
rityNumber_Type

o A FOREIGN KEY constraint that references a customer's id from the
Sales table would be named: FK_Customers_Custome
rID_Sales_CustomerID

o A CHECK constraint on the Total column from the Sales table would
be named: CK_Sales_Total

o A DEFAULT constraint on the Total column from the Sales table would
be named: DF_Sales_Total

5.. Indexes
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Index names should be prefixed with the IDX_

· Following the IDX_ prefix, the type of index, CL_ for a clustered
index and NC_ for a non-clustered index should be appended

· Following the index type identifiers, U_ should be appended for
unique indexes and NU_ should be appended for a non-unique indexes

· Following the type and uniqueness identifiers, the table name
(including underscore) should be appended

· Following the table name, the column(s) to which the index applies
should be appended (separated with underscores for multiple columns if
needed)

· Examples:

o A unique clustered index on a customer's last name then first name
in the Customers table would be named:
IDX_CL_U_Customers_L
astName_FirstName

o A non-unique non-clustered index on a customer's last name then
first name in the Customers table would be named:
IDX_NC_NU_Customers_
LastName_FirstName

6.. Triggers
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Trigger names should be prefixed with TRG_

· Following the TRG_ prefix, the type of trigger should be specified
Insert = I_, Update = U_, Delete = D_ (for multiple actions include each
action without underscores between each)

· Following the trigger and type identifiers, the table name
(including underscore) should be included

· Following the table name, the column to which the trigger applies
should be appended

· Examples:

o An update trigger on the Total column in the Sales table would be
named: TRG_U_Sales_Total

o An insert, update and delete trigger on the Status column of the
Sales table would be named: TRG_IUD_Sales_Status

7.. Stored Procedures
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Each stored procedure should begin with a capitalized 2 to 3
letter combination prefix (with underscore) that uniquely identifies the
application to which the stored procedure belongs i.e., Dataminer = DM_,
Electronic Service Report = ESR_

· Following the application identifier, each stored procedure should
include a sp_ entry to identify the object as a stored procedure

· Following the application and stored procedure identifiers, each
stored procedure should have a 1 to 6 word name (short as possible) that
identifies the purpose or functionality of the stored procedure. Using
standard verbs like "Create", "Add", "Get", "Update", "Delete" etc. at the
start of the name will allow common types of tasks to be grouped together
and is encouraged.

· Examples:

o A stored procedure for the Dataminer application to get the down
time would be named: DM_sp_GetDownTime

8.. Views
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Each view should begin with a capitalized 2 to 3 letter
combination prefix (with underscore) that uniquely identifies the
application to which the view belongs i.e., Dataminer = DM_, Electronic
Service Report = ESR_

· Following the application identifier, each view should have a vw_
entry to identify the object as a view

· Following the application and view identifiers, each view should
have a 1 to 6 word name (short as possible) that identifies the purpose or
functionality of the view. Using standard words like "Top", "Bottom",
"Worst", etc. at the start of the name will allow common types of reports to
be grouped together and is encouraged.

· Examples:

o A view for the Dataminer application to list the top ten alarms
would be named: DM_vw_Top10Alarms

9.. User-defined Functions
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Each user-defined function should begin with a capitalized 2 to 3
letter combination prefix (with underscore) that uniquely identifies the
application to which the user-defined function belongs i.e., Dataminer =
DM_, Electronic Service Report = ESR_

· Following the application identifier, each user-defined function
should next have a fn_ entry to identify the object as a user-defined
function

· Following the application and user-fined function identifiers,
each user-defined function should have a 1 to 3 word name (short as
possible) that identifies the purpose or functionality of the user-defined
function. Using standard words like "Convert", "Change", "Format", etc. at
the start of the name will allow common types of functionalities to be
grouped together and is encouraged.

· Examples:

o A user-defined function for the Dataminer application to format a
date would be named: DM_fn_FormatDate

10.. User-defined Data Types
· DO NOT USE USER-DEFINED DATA TYPES - USE SYSTEM SUPPLIED DATATYPES
INSTEAD

11.. Defaults and Rules
· DO NOT USE DEFAULTS AND RULES - USE DEFAULT CONSTRAINTS AND CHECK
CONSTRAINTS INSTEAD

12.. Variables and Parameters
In addition to the General Naming Guidelines for all Database Objects listed
above:

· Each variable and parameter should be preceded with the @ symbol

· Following the @ symbol each variable or parameter should have a 1
to 3 word name

· The variable or parameter name should not include the data type
(or abbreviation) of the variable or parameter

· Use meaningful names for short-lived variables (i.e., loop
counters) as well

General Notes on SQL Code Formatting

a.. Whenever possible use pre-existing Query Analyzer T-SQL code templates
to improve coding efficiency
b.. All SQL code should be formatted for legibility and understanding
c.. Appropriate white space should be used to facility code readability
d.. All code should be commented liberally using inline (--) and block
(/*.*/) comments to facilitate code comprehension and self-documentation.
All code that is not readily understandable should be commented to convey
meaning and/or purpose whenever possible.
e.. Database objects should be referenced in code using the same case in
which they were defined
f.. All T-SQL keywords should be capitalized
g.. Begin each T-SQL clause on a separate line
h.. Avoid very long lines of T-SQL code; consider breaking the code into
multiple lines to increase readability
i.. Align all beginning and ending T-SQL code blocks (i.e., BEGIN.END)
j.. Use tabs to align code blocks and to indent sub-queries
k.. Use a lowercase 1 to 2 character table aliases when referencing tables
in queries
l.. Use column aliases to improve result set readability
m.. Place each column in the SELECT list on a separate line preceded with
a comma (exception - first column)
n.. Each stored procedure, view and user-defined function should have the
following header comment information following the CREATE statement and
prior to any code:
/*

NAME:

DESCRIPTION:

AUTHOR:

CREATION DATE:

APPLICATION:

OBJECT:

DATABASE:

SPECIAL INSTRUCTIONS:

EXAMPLE:

LAST MODIFIED DATE:

REVISION HISTORY:

/*

a.. All revision documentation should be maintained and should be current
and up-to-date at all times
b.. One script (.sql) file per object
c.. Each script (.sql) file should have the name of the object
d.. All script (.sql) files should be stored in the source control system

David Gugick

2006-02-06, 8:23 pm

Jerry Spivey wrote:
> Hi,
>
> I've been putting together a database naming convention standard for
> our SQL developers the last couple of days. I've chosen a more
> verbose standard to help reign in my developers and to help improve
> the documentation, use and understanding of their T-SQL code. I've
> looked over it a few times but it is all starting to look the same to
> me ;-) If anyone is interested in providing me with a sanity check
> for the document and provide "useful" feedback without slamming
> criticism I'd appreciate it. Again, the verboseness of the standard
> is by design.
> Thanks all.
>
> Jerry
>
> SQL Server
>
> Database Naming Conventions
>
>
>
>
>
> Purpose
>
>
>
> The purpose of creating and adopting a standardized database naming
> convention is to ensure that all database objects and/or their
> purpose or function is easily identifiable and understandable to all
> parties who create and/or reference these objects in application code
> and reports. "Consistent use" is the key to the success of a
> standardized database naming convention. This database naming
> convention is designed to be more verbose to facilitate
> self-documentation and to improve code understanding.
>
>
> General Naming Guidelines for all Database Objects
>
>
>
> a.. Use an object name that is easily understandable (short and
> meaningful)
> b.. Use an object name that easily identifies the purpose or
> functionality of the object
> c.. Use prefixes instead of suffixes to identify the type of object
> d.. Limit the number of characters in each object name (< 30
> characters whenever possible)
> e.. Limit the use of numbers in object names (use only letters and
> underscores whenever possible)
> f.. Use a character for the first letter in an object name
> g.. Limit the use of underscores in object names (use Pascal case
> notation for the object name following the application and object
> type identifiers) h.. Avoid using abbreviations in object names
> i.. Avoid using acronyms in object names
> j.. Avoid using T-SQL special meaning characters i.e., @, %, #, ##
> k.. Do not use spaces in object names
> l.. Do not use hyphens (dashes) in object names
> m.. Do not use any SQL Server or ODBC reserved keywords in object
> names (see SQL Server Books Online for a complete listing)
> n.. Ensure the dbo user is the owner of all database objects; always
> prefix the object name with dbo
> a.. Example: CREATE TABLE dbo.DM_tbl_Employees
>
>
>
>
> Object Types
>
>
>
> 1.. Databases
> 2.. Tables
> 3.. Columns
> 4.. Constraints
> 5.. Indexes
> 6.. Triggers
> 7.. Stored Procedures
> 8.. Views
> 9.. User-defined Functions
> 10.. User-defined Data Types
> 11.. Defaults and Rules
> 12.. Variables and Parameters
>
>
> 1.. Databases
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Ensure the database name chosen easily identifies the
> purpose, function, application or department for which the database
> will be used
>
>
> 2.. Tables
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Use prefixes instead of suffixes in identifying tables. The
> exception to this rule is when a table is being partitioned into
> multiple parts i.e., year. In this case, _year can be appended to
> the table names to differentiate the tables i.e., DM_tbl_Sales_1995.
>
> · Each table should begin with a capitalized 2 to 3 letter
> combination prefix (with underscore) that uniquely identifies the
> application to which the table belongs i.e., Dataminer = DM_,
> Electronic Service Report = ESR_
>
> · Following the application identifier, each table should
> have a tbl_ entry to identify the object as a table
>
> · Following the application and table identifiers, each table
> should have a 1 to 3 word name that identifies the contents of the
> table. Plural names should be used i.e., Customers instead of
> Customer
> · Examples:
>
> o The customers table for the Data Miner application would be
> named: DM_tbl_Customers
>
> o The scanned invoices table for the Electronic Service Report
> application would be named: ESR_tbl_ScannedInvoi
ces
>
>
>
> 3.. Columns
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Each column should have a 1 to 3 word name
>
> · The table name should not be included in the column name
> with the exception of the ID (or PK) column for the table i.e.,
> CustomerID
> · The join column between tables should have the same name
>
> · Boolean columns should be prefixed with a "Is" or "Has"
> i.e., IsApproved (0 = NO/FALSE; 1= YES/TRUE )
>
> · The column name should not include the data type (or
> abbreviation) of the column
>
> · Always include NULL or NOT NULL for each column defined
>
>
>
> 4.. Constraints
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Each constraint should be given a user-defined name instead
> of the system supplied name
>
> · Each constraint should have a capitalized two letter
> combination prefix (with underscore) that identifies the type of
> constraint: PRIMARY KEY = PK_, FOREIGN KEY = FK_, UNIQUE = UC, CHECK
> = CK, DEFAULT = DF
> · By default when a PRIMARY KEY constraint is created a
> clustered index is created behind-the-scenes to support the
> constraint functionality. For clustered PRIMARY KEY constraints,
> append CL_ to the object name and for non-clustered PRIMARY KEY
> constraints append NC_ to the object name
> · By default when a UNIQUE constraint is created a
> non-clustered index is created behind-the-scenes to support the
> constraint functionality. For clustered UNIQUE constraints, append
> CL_ to the object name and for non-clustered UNIQUE constraints
> append NC_ to the object name
> · Following the constraint identifier prefix, the table name
> (with underscore) should be appended
>
> · Following the table name, the column(s) to which the
> constraint applies should be appended (separated with underscores for
> multiple columns if needed)
>
> · For FOREIGN KEY constraints, the table name and column from
> both the referenced (parent) table and the child (referencing) table
> should be included i.e, parent_parentcolumn_
child_childcolumn (parent
> listed first)
> · Examples:
>
> o A PRIMARY KEY constraint (clustered index) on the CustomerID
> column in the Customers table would be named:
> PK_CL_Customers_Cust
omerID
> o A PRIMARY KEY constraint (non-clustered index) on the
> CustomerID column in the Customers table would be named:
> PK_NC_Customers_Cust
omerID
> o A UNIQUE constraint (clustered index) on the SecurityNumber
> column in the Customers table would be named:
> UC_CL_Customers_Secu
rityNumber
> o A UNIQUE constraint (non-clustered index) on the
> SecurityNumber column in the Customers table would be named:
> UC_NC_Customers_Secu
rityNumber
>
> o A UNIQUE constraint (clustered index) on the SecurityNumber
> and Type columns in the Customers table would be named:
> UC_CL_Customers_Secu
rityNumber_Type
>
> o A FOREIGN KEY constraint that references a customer's id
> from the Sales table would be named:
> FK_Customers_Custome
rID_Sales_CustomerID

> o A CHECK constraint on the Total column from the Sales table
> would be named: CK_Sales_Total
>
> o A DEFAULT constraint on the Total column from the Sales
> table would be named: DF_Sales_Total
>
>
>
> 5.. Indexes
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Index names should be prefixed with the IDX_
>
> · Following the IDX_ prefix, the type of index, CL_ for a
> clustered index and NC_ for a non-clustered index should be appended
>
> · Following the index type identifiers, U_ should be appended
> for unique indexes and NU_ should be appended for a non-unique indexes
>
> · Following the type and uniqueness identifiers, the table
> name (including underscore) should be appended
>
> · Following the table name, the column(s) to which the index
> applies should be appended (separated with underscores for multiple
> columns if needed)
>
> · Examples:
>
> o A unique clustered index on a customer's last name then
> first name in the Customers table would be named:
> IDX_CL_U_Customers_L
astName_FirstName
>
> o A non-unique non-clustered index on a customer's last name
> then first name in the Customers table would be named:
> IDX_NC_NU_Customers_
LastName_FirstName
>
>
>
> 6.. Triggers
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Trigger names should be prefixed with TRG_
>
> · Following the TRG_ prefix, the type of trigger should be
> specified Insert = I_, Update = U_, Delete = D_ (for multiple actions
> include each action without underscores between each)
>
> · Following the trigger and type identifiers, the table name
> (including underscore) should be included
>
> · Following the table name, the column to which the trigger
> applies should be appended
>
> · Examples:
>
> o An update trigger on the Total column in the Sales table
> would be named: TRG_U_Sales_Total
>
> o An insert, update and delete trigger on the Status column of
> the Sales table would be named: TRG_IUD_Sales_Status

>
>
>
> 7.. Stored Procedures
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Each stored procedure should begin with a capitalized 2 to 3
> letter combination prefix (with underscore) that uniquely identifies
> the application to which the stored procedure belongs i.e., Dataminer
> = DM_, Electronic Service Report = ESR_
>
> · Following the application identifier, each stored procedure
> should include a sp_ entry to identify the object as a stored
> procedure
> · Following the application and stored procedure identifiers,
> each stored procedure should have a 1 to 6 word name (short as
> possible) that identifies the purpose or functionality of the stored
> procedure. Using standard verbs like "Create", "Add", "Get",
> "Update", "Delete" etc. at the start of the name will allow common
> types of tasks to be grouped together and is encouraged.
>
> · Examples:
>
> o A stored procedure for the Dataminer application to get the
> down time would be named: DM_sp_GetDownTime
>
>
>
> 8.. Views
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Each view should begin with a capitalized 2 to 3 letter
> combination prefix (with underscore) that uniquely identifies the
> application to which the view belongs i.e., Dataminer = DM_,
> Electronic Service Report = ESR_
>
> · Following the application identifier, each view should have
> a vw_ entry to identify the object as a view
>
> · Following the application and view identifiers, each view
> should have a 1 to 6 word name (short as possible) that identifies
> the purpose or functionality of the view. Using standard words like
> "Top", "Bottom", "Worst", etc. at the start of the name will allow
> common types of reports to be grouped together and is encouraged.
>
> · Examples:
>
> o A view for the Dataminer application to list the top ten
> alarms would be named: DM_vw_Top10Alarms
>
>
>
> 9.. User-defined Functions
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Each user-defined function should begin with a capitalized
> 2 to 3 letter combination prefix (with underscore) that uniquely
> identifies the application to which the user-defined function belongs
> i.e., Dataminer = DM_, Electronic Service Report = ESR_
>
> · Following the application identifier, each user-defined
> function should next have a fn_ entry to identify the object as a
> user-defined function
>
> · Following the application and user-fined function
> identifiers, each user-defined function should have a 1 to 3 word
> name (short as possible) that identifies the purpose or functionality
> of the user-defined function. Using standard words like "Convert",
> "Change", "Format", etc. at the start of the name will allow common
> types of functionalities to be grouped together and is encouraged.
>
> · Examples:
>
> o A user-defined function for the Dataminer application to
> format a date would be named: DM_fn_FormatDate
>
>
>
> 10.. User-defined Data Types
> · DO NOT USE USER-DEFINED DATA TYPES - USE SYSTEM SUPPLIED
> DATATYPES INSTEAD
>
>
>
> 11.. Defaults and Rules
> · DO NOT USE DEFAULTS AND RULES - USE DEFAULT CONSTRAINTS AND
> CHECK CONSTRAINTS INSTEAD
>
>
>
> 12.. Variables and Parameters
> In addition to the General Naming Guidelines for all Database Objects
> listed above:
>
> · Each variable and parameter should be preceded with the @
> symbol
> · Following the @ symbol each variable or parameter should
> have a 1 to 3 word name
>
> · The variable or parameter name should not include the data
> type (or abbreviation) of the variable or parameter
>
> · Use meaningful names for short-lived variables (i.e., loop
> counters) as well
>
>
>
>
>
> General Notes on SQL Code Formatting
>
>
>
> a.. Whenever possible use pre-existing Query Analyzer T-SQL code
> templates to improve coding efficiency
> b.. All SQL code should be formatted for legibility and understanding
> c.. Appropriate white space should be used to facility code
> readability d.. All code should be commented liberally using inline
> (--) and block (/*.*/) comments to facilitate code comprehension and
> self-documentation. All code that is not readily understandable
> should be commented to convey meaning and/or purpose whenever
> possible. e.. Database objects should be referenced in code using
> the same case in which they were defined
> f.. All T-SQL keywords should be capitalized
> g.. Begin each T-SQL clause on a separate line
> h.. Avoid very long lines of T-SQL code; consider breaking the code
> into multiple lines to increase readability
> i.. Align all beginning and ending T-SQL code blocks (i.e.,
> BEGIN.END) j.. Use tabs to align code blocks and to indent
> sub-queries k.. Use a lowercase 1 to 2 character table aliases when
> referencing tables in queries
> l.. Use column aliases to improve result set readability
> m.. Place each column in the SELECT list on a separate line preceded
> with a comma (exception - first column)
> n.. Each stored procedure, view and user-defined function should
> have the following header comment information following the CREATE
> statement and prior to any code:
> /*
>
> NAME:
>
> DESCRIPTION:
>
> AUTHOR:
>
> CREATION DATE:
>
> APPLICATION:
>
> OBJECT:
>
> DATABASE:
>
> SPECIAL INSTRUCTIONS:
>
> EXAMPLE:
>
> LAST MODIFIED DATE:
>
> REVISION HISTORY:
>
> /*
>
> a.. All revision documentation should be maintained and should be
> current and up-to-date at all times
> b.. One script (.sql) file per object
> c.. Each script (.sql) file should have the name of the object
> d.. All script (.sql) files should be stored in the source control
> system

http://vyaskn.tripod.com/object_naming.htm
http://www.amazon.com/gp/product/01...glance&n=283155

--
David Gugick - SQL Server MVP
Quest Software

Sponsored Links