Download Objects Naming Standards

Table of Contents
Document Manager ......................................................................................................... 2
Introduction ...................................................................................................................... 3
Objects Naming Standards ............................................................................................. 4
 Databases .............................................................................................................. 5
 Schemas................................................................................................................. 5
 Tables .................................................................................................................... 5
 Views ..................................................................................................................... 7
 Columns ................................................................................................................ 8
 Stored Procedures ............................................................................................... 8
 Triggers ................................................................................................................. 9
 User-Defined Functions ................................................................................... 11
 User-Defined Data Types ................................................................................ 12
 Indexes ................................................................................................................ 13
 Constraints ......................................................................................................... 14
Document Manager
Date
ChangedBy ApprovedBy
ChangedSections
ChangesRemarks
2
Introduction
This document provides the set of standards that has to be followed
for database design and development in UST-Global using
Microsoft SQL Server all versions.
3
Objects Naming Standards
This section explains the naming conventions that have to be
followed while designing and developing the objects within the
database. While naming an object, we need to ensure that the
object name conveys enough information such as the type of
object and the purpose of the object.
The following objects are covered in this section–
1. Databases
2. Schemas
3. Tables
4. Columns
5. Views
6. Stored Procedures
7. Triggers
8. User-Defined Functions
9. User-Defined Data Types
10. Indexes
11. Constraints
The following set of guidelines is common to all objects. Ensure
that these guidelines are strictly enforced while naming
database objects –
1. Use Title cases for object names; use TxPr_UserProfile
instead of TXPR_USERPROFILE or txpr_userprofile.
NOTE: If the database would require using a case sensitive
collation setting, use either lower cases or upper case for all
the object names
2. Do not use “dots” (.) in between object names; usage of dots
will create problems while using fully qualified names.
3. Do not use reserved key words as object names.
4. Do not use numbers in between object names such as
TxPr_UserProfile1 etc. If the application requires that
dynamic tables be created that use periods such as month,
semester trimester etc be included as part of an object name,
4
suffix the period after an underscore. Example hrPayRoll_Dec2008, TxPrEventLog_12312008 etc.
5. Avoid using generic prefixes such as “db_” for databases,
“tbl_” for tables, “proc_” for stored procedures etc. This will
create unnecessary overhead and redundancy, and will
reduce the search speed. However, there are exceptions to
this. Using a prefix “vw_” shall be used for views because
while using a view in a SELECT, UPDATE, DELETE or
INSERT query it will help us distinguish whether we are
using a table or a view. Similarly, when having a prefix Udf_
will be helpful in differentiating between User-defined
Functions and built-in functions. Also, using a prefix Udt_
will helpful in differentiating User-defined Data Types and
built-in data types.
 Databases
Databases are used to store and manage data securely and
efficiently. It is important to ensure that the name of the
database meaningfully denotes the business or the application
and should effectively convey the purpose of the database.
Consider that we have a HRM application. The database should be
ideally named as “HRM”. If there are multiple databases for the
same HRM application, avoid using numbers to distinguish the
databases like “HRM1”, “HRM2” etc. Rather, we should use
HRM_<purpose>. For example, if there is a database that acts as
a data warehouse for the application, then it can be named as
“HRM_DW”.
 Schemas
Schema is a logical grouping of objects within a database. Schemas
were introduced with SQL Server 2005 which adds an extra
level of grouping and security for database objects.
Similar to the naming standards for Databases, Schema names
should effectively convey the purpose of the Schema. Consider
that the database belongs to an ERP application. We can
logically group the data according to the departments or units
such as Human Resources, Sales, Marketing, and Operations
etc. To hold the data belonging to the different departments, we
can create Schemas with names “hr”, “sales”, “marketing”,
“operations” etc.
 Tables
5
Tables contain the instances of an entity. On contrary to databases
or schemas, the number of tables in an application will be very
huge. Hence, it is very important that we ensure that the table
names will convey the correct message and that name should
reflect the purpose of the table as close as possible.
The following guidelines have to be enforced while naming a table–
1. If there are multiple modules in the application, the table name
should start with a first 1 to 4 letters denoting the module to
which the table belongs to.
For example, if the table corresponds to the Tax Processing module,
the table names can be TxPr_UserProfile, TP_UserProfile etc.
2. The stored procedures, views, constraints etc are built upon
specific tables. So, use underscores (_) judiciously so that there
will not be a large number of underscores in a constraint name
or a procedure name.
 Backup Tables
If the application creates backup tables as part of the processes,
name the table as
Backup_<original_table_name>_<mmddyyyy>. This way we
can track the creation of the backup tables and remove outdated
backup tables. However, we can change the timestamp based
upon how frequently the application or the user creates the
backup tables. In such cases, we can change the naming
standard to
Backup_<original_table_name>_<mmddyyyyhhmmss> or so,
according to the frequency of the table creations.
However, if the backup tables are created by a dba or a developer,
the name should include the user’s name as well. In such cases,
the backup table should be named as
Backup_<original_table_name>_<user_name>_<mmddyyyy>
 Temporary Tables
If the application requires temporary tables created beforehand for
storing intermediate results etc, name the table as
tmp_<original_table_name>.
 ChangeLog/History Tables
6
There will be change log tables or history tables in applications that
store information on the changes like insert, delete or update
that happen to a particular table. These tables are not normally
considered as part of the application, but they are mostly part of
the monitoring, tracking or version control management of the
DBAs and developers. Such tables have to be named as
ChangeLog_<original_table_name>. For example, if we have a
table that tracks the changes in the table TxPr_UserProfile, that
table should be named as ChangeLog_TxPr_UserProfile.
However, if the change log tables are part of the application, and if
these tables are referenced within the application for some
activities, then we need to change the naming standard so that
the phrase ChangeLog should come as a suffix instead of a
prefix. In such a case, the above ChangeLog table for the
TxPr_UserProfile table in the above example will become
TxPr_UserProfile_ChangeLog.
 Views
Views are stored query definitions which can be called by a name
and can be used for DML activities similar to tables (An
exception here is an Indexed View where the view is physically
materialized).
The following guidelines have to be enforced while naming a view–
1. Views should be named with a prefix of “vw_”. Since views can
be used very much similar to tables, prefixing with a vw_ will
help us understand that the object being referenced is a view
and not a table.
2. A view is created out of one or more tables. The name of a view
should easily convey which tables the view got created from.
The name should be in the format
vw_<tableName1>_<tableName2>, where the tables referenced
by the view should be separated by an underscore.
For example, if we create a view from tables TxPr_UserProfile and
TxPr_Users, the view should be named as
“vw_TxPr_UserProfile_TxPr_Users”.
However, there can be exceptions to this standard where there are
too many tables (more than 4) being referenced by the view for
complex queries. In such cases, we can ignore this rule and add
a phrase that denotes the purpose of the view. Even in such a
case, rule #1 and rule #3 should be strictly satisfied.
7
3. An indexed view should be named with a prefix of “vwIdx_”.
Henceforth, an indexed view created on TxPr_UserProfile table
should be named as vwIdx_ TxPr_UserProfile.
 Columns
Columns contain the attributes of instances. Column names should
be clear enough that no extra explanation should be required to
understand the requirement of the column.
The following guidelines have to be enforced while naming a
column–
1. Avoid using underscores within column names.
 Stored Procedures
Stored Procedures control the business rules of any application.
Stored Procedures are the objects that get the maximum altered
in any application; new stored procedures will be added and
existing procedures will be altered more frequently than we
create or alter tables. Also, in very complex processing oriented
applications, there will be a large number of procedures
compared to the number of tables or views. Hence, it is very
important that the procedure names are clear, easily
distinguishable and conveys the purpose of the procedure.
The following guidelines have to be enforced while naming a
stored procedure–
1. Never start a procedure name with sp_
2. The procedure name should start with the general prefix that is
being used for the module or process to which the procedure
belongs. For example, procedures that belong to the Tax
Processing module should start with the
TxPr_<procedureName>, those belong to Payroll Processing
should start with PayPr_<procedureName>, those used for
Monitoring module should start with Mon_<procedureName>
etc.
3. The second part of the procedure name should convey the
activity the procedure will do. For example, if we have a
procedure that will insert to the Payroll Processing
PyPr_EventLog table, it shall be named as
PyPr_Insert_PyPr_EventLog.
In most cases the procedure and the table(s) will belong to the same
module; in such cases, we can ignore the module/process prefix
8
for the table names. So, the above procedure can be named as
PyPr_Insert_EventLog. If the modules/processes are different,
we should strictly include the full names of the tables used.
However, there can be more “activities” procedures will do in an
application apart from the regular SELECT, INSERT, UPDATE
or DELETE activities. These can be activities such as
“Calculate”, “Tracking”, and “Notifying” etc. Such activities
may not be confined to a single table. For example, the monthly
pay calculation for an employee may not be confined to a
process involved by a single table. In such cases, meaningful
names have to be given to the procedure like
PyPr_Calculate_MonthlyPay
4. The third part of the procedure name should denote the
purpose of the procedure.
For example, , the procedure that calculates the annual incentives
of a given employee can be named as
PyPr_Calculate_AnnualIncentives, the procedure that sends
email notification to an employee that his salary has been
credited can be named as PyPr_Notify_SalaryCredited etc.
5. Do not use any underscores in the “purpose” part of the
procedure name.
In short, the name of a procedure should be of the below format –
<module/process name>_<activity>_<purpose>.
 Triggers
Triggers are procedures that will fire automatically by any DML or
DDL activity.
 DML Triggers
A DML trigger gets fired triggered by an INSERT, DELETE or
UPDATE on a table.
The following guidelines have to be enforced while naming a DML
trigger–
1. The trigger name should start with the general prefix that is
being used for the module or process to which the trigger
belongs. For example, a trigger that belongs to the Tax
Processing module should start with the TxPr_ those belong to
Payroll Processing should start with PayPr_, those used for
Monitoring module should start with Mon_ etc.
9
2. The second part of the trigger name should denote the activity
the trigger will be fired upon. For example, if we have a trigger
that will get fired upon the insertion of a record into the Payroll
Processing PyPr_Users table, it shall be started as
PyPr_Insert_Users.
3. The third part of the trigger name should denote the name of
the table on which the trigger is created.
Since a DML trigger is confined to a single table, there can be cases
where we feel that adding the base table name is not required.
However, adding the base table name can be helpful while
extracting information on triggers from DMVs. In case adding
the base table name increases the object name a lot, then we can
ignore this rule. But, strictly ensure that the standard is
maintained for all the DML triggers.
4. The fourth part of the trigger name should denote the purpose
of the trigger. Consider that following to every User creation,
there will be an event logging mechanism that notifies the new
user that his login has been created. So, following to the new
record insertion into the PyPr_Users, a trigger should fire a
notification email to the user. Such a trigger can be named as
PyPr_Insert_Users_NotifyUserCreation.
 DDL Triggers
DDL triggers are triggers that get fired upon a DDL activity like
schema change, logon etc. These DDL triggers can have a scope
of the entire server or within a single database. The events that
can be tracked on both the scopes can be broadly classified as
security related and schema change related.
The following guidelines have to be enforced while naming a DDL
trigger–
1. The first part of the trigger name should be TrigDDL_
2. The second part of the trigger name should be the scope of the
trigger followed by an underscore; if the scope is database, the
name should start as TrigDDL_Db_ and for a server scope, it
should be TrigDDL_Srv_
3. If the DDL trigger is of database scope, the third part of the
trigger name should be the database name followed by an
underscore. So, a DDL trigger on the HRM database should
start as TrigDDL_Db_HRM_
10
However, as mentioned in the rule # 3 for DML triggers, the
database name can skipped if not required. But, the standard
should be maintained across all the database scoped DDL
triggers.
4. The fourth part of the DDL trigger name should be the purpose
of the trigger. For example, if we create this trigger to track the
schema changes in the HRM database, the name shall be
TrigDDL_Db_HRM_TrackSchemaChanges, if the trigger is to
track new database user creation the name shall be
TrigDDL_Db_HRM_TrackUserChanges, if the trigger is a
server scope trigger that should track the creation of logins the
name shall be TrigDDL_Srv_TrackLoginChanges etc.
 User-Defined Functions
User-defined functions (UDFs) in SQL Server are routines that
accept parameters, perform an action and return the result of
that action as a value.
The following guidelines have to be enforced while naming a Userdefined Function–
1. The first part of the UDF name should be Udf_
2. The second part of the UDF name should have the general
prefix that is being used for the module or process to which the
UDF belongs. For example, a UDF that belongs to the Tax
Processing module should have _TxPr_ those belong to Payroll
Processing should have _PayPr_, those used for Monitoring
module should have _Mon_ etc.
3. The third part of the UDF name should convey the activity the
UDF will do. For example, if we have a UDF that will insert to
the Payroll Processing PyPr_EventLog table, it shall be named
as Udf_PyPr_Insert_PyPr_EventLog.
In most cases the UDF and the table(s) will belong to the same
module; in such cases, we can ignore the module/process prefix
for the table names. So, the above procedure can be named as
Udf_PyPr_Insert_EventLog. If the modules/processes are
different, we should strictly include the full names of the tables
used.
However, most probably “activities” UDFs will do in an
application will be more complex than the regular SELECT,
INSERT, UPDATE or DELETE activities. These can be activities
such as “Calculate”, “Tracking”, and “Notifying” etc. Such
activities may not be confined to a single table. For example, the
11
monthly pay calculation for an employee may not be confined
to a process involved by a single table. In such cases,
meaningful names have to be given to the UDF like
Udf_PyPr_Calculate_MonthlyPay
 User-Defined Data Types
User-Defined Data Types (UDTs) are custom data types that can be
defined by a user built upon any of the base data types defined
within MS SQL Server.
The following guidelines have to be enforced while naming a Userdefined Data Type–
1. The first part of the UDT name should be Udt_
2. The second part of the UDT name should have the general
prefix that is being used for the module or process to which the
UDT belongs. For example, a UDT that belongs to the Tax
Processing module should have _TxPr_ those belong to Payroll
Processing should have _PayPr_, those used for Monitoring
module should have _Mon_ etc.\
If the UDT being created will have to be used for more than one
module/process, this rule has to be ignored.
3. One of the main purposes of using UDTs is to enforce consistent
column data type definitions across the entire database.
For example, if we have a UserId column in the application
database which is used across the entire database. If we need to
enforce that the UserId column will have a data type CHAR (12)
in the entire database, we can define a UDT with CHAR (6) and
use that UDT as the data type for all the UserId columns in the
database.
In such cases, the third part of the UDT name should have the
column name for which the UDT will be used for. In the
example above, the UDT created for the UserId column should
be named as Udt_PayPr_UserId. If this UDT is going to be used
by more than one module/process, it has to be named as
Udt_UserId.
4. Another purpose of UDT is to create data types that are not
defined by-default in SQL Server. For example, until SQL Server
2005, we don’t have a “2 Dimensional location” data type where
we can use a (x, y) co-ordinate location for a point. If our
application needs to have a “2dLocation” UDT, it may not be
confined to a single column as we discussed in rule # 3. In such
12
cases, instead of using the column name as the third part of the
UDT name, use a meaningful phrase that denotes the purpose
of the UDT. Then, the UDT for 2D Location will become
Udt_PayPr_2DLocation or Udt_2DLocation based upon
whether the UDT will be used by more than one
module/process or not.
 Indexes
The following guidelines have to be enforced while naming an
Index–
1. The first part of the Index name should have a prefix Idx
followed by the type of Index being created. The following table
illustrates the different types and how the first part of the Index
name varies accordingly.
IndexType
Unique, Clustered
Unique, Non-Clustered
Non-Unique, Clustered
Non-Unique, Non-Clustered (Included Columns)
Unique, Non-Clustered
Non-Unique, Non-Clustered (Included Columns)
XML Indexes - Primary
XML Indexes - Secondary
Prefix
IdxUqCl_
IdxUqNc_
IdxNuCl_
IdxNuNcIncl_
IdxUqNc_
IdxNuNcIncl_
IdxXmlPr_
IdxXmlSc_
2. The second part of the Index name should denote the name of
the column on which the Index is being created. For example, if
a unique non-clustered index is being created on the UserId
column, the Index name should be IdxUqNc_UserId.
It is possible that we declare composite indexes. In such cases,
include the column names separated by an underscore. In the
above example, if the index is being created on UserId and
DeptName columns, the index name should become
IdxUqNc_UserId_DeptName
3. If the non-clustered index we create has included columns,
following to the list of index columns, we need to add a suffix
_INCL_ followed by the columns that are getting included. In
the above example, if we decide to include the column
DeptHead, the index name should become
IdxUqNcIncl_UserId_DeptName_INCL_DeptHead
13
If there are a large number of index columns and included
columns, we can use appropriate acronyms for column names
so that the index name will not become very large.
 Constraints
The following guidelines have to be enforced while naming a
constraint–
 Primary Key Constraints
1. The name of a primary key should start with Pk_
2. The second part of a primary key should denote the name of the
column on which it is being created. For example, the primary
key constraint name for the table PyPr_EventLog on column
LogId has to be started with Pk_LogId.
It is possible that we declare composite primary keys; in such cases,
append the names of all the columns separated with an
underscore. For example, if we need to create a composite
primary key on the UserId, UserName columns of the
PyPr_Users table, we should name it as Pk_UserId_UserName.
If there are a large number of columns on the key, we can use
appropriate acronyms for column names so that the key name
will not become very large.
 Foreign Key Constraints
1. The name of a foreign key should start with Fk_
2. The second part of a foreign key should denote the name of the
column on which it is being created. For example, the foreign
key constraint name for the table PyPr_EventLog on column
UserId has to be started with Fk_UserId.
3. Following to the column name on which the foreign key is being
created, we should add the phrase _REF_
4. Following to the _REF_ phrase, enter the name of the table
which the foreign key is referencing. For example, if we are
creating a foreign key on the PyPr_EventLog.UserId column
that references PyPr_Users.UserId column, the foreign key
name should start with Fk_UserId_REF_Users_
5. Followed by the table name the foreign key references, add the
name of the column on which the reference is being made. In
the above example, the name of the foreign key should become
Fk_UserId_REF_Users_UserId.
14
If the foreign key is referencing a composite primary key, each of
the column names should be listed separated by an underscore.
In the above example, if the primary key on the PyPr_Users
table is on UserId and UserName columns, the name of the
foreign key will become
Fk_UserId_UserName_REF_Users_UserId_UserName
If there are a large number of columns on the key, we can use
appropriate acronyms for column names so that the key name
will not become very large.
 Unique Constraints
1. The name of a Unique constraint should start with Uq_
2. The second part of a Unique constraint should denote the name
of the column on which it is being created. For example, the
Unique constraint name for the table PyPr_Users on column
UserId has to be Uq_UserId
 Default Constraints
3. The name of a Default constraint should start with Df_
4. The second part of a Default constraint should denote the name
of the column on which it is being created. For example, the
Default constraint name for the table PyPr_EventLog on column
LogTime has to be Df_LogTime.
 Check Constraints
1. The name of a Check constraint should start with Chk_
2. The second part of a Check constraint should denote the name
of the column on which it is being created. For example, the
Check constraint name for the table PyPr_Users on column
Password has to be Chk_Password
15