Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Microsoft SQL Server wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Functional Database Model wikipedia , lookup
Clusterpoint wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Ingres (database) wikipedia , lookup
Relational model wikipedia , lookup
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