Do not use reserved words, special characters, or start names with a number. Try to avoid the use of abbreviations. Abbreviations make it very difficult for other people to determine what an object does. Naming conventions are neither right nor wrong. They will simply provide a standard way of referencing objects in the database and should eliminate a lot of questions as to the function of a particular object if used properly. If abbreviations are used, they must follow the set of standard abbreviations set specified elsewhere in your set of standards.As you can tell from most of the naming conventions, I like proper cased names (CustomerInvoice) and dislike underscores as well. This is simply because very few people type in all caps. Databases:User databases shall be named in all proper cased letters. Example: Customer, Accounting, Master Logins:Logins shall consist of the first letter of the person’s first name and the full last name. All logins shall consist of lower case letters. The exceptions to this are any system level or administrative logins. The sa (system administrator login should be locked up and never used except for those needing system level access). A separate account should be created for the dbo. This gives the ability for a single account to own all of the databases and objects, but still not have system level access. Example: mhotek, swynkoop, dbadmin Tables:Tables shall be named with words describing their purpose. Names should be in all proper case with words run together. Lookup tables shall be preceded by a zlk_. The z allows grouping all of these tables at the bottom of the list (most query tools list tables alphabetically) and the lk_ designates that this is a lookup or auxiliary table. Example: CustomerAddress, Customer, PeopleMailinglist, zlk_CountryCodes Columns:Columns shall be named with words describing their purpose. The first letter of each word at a minimum shall be capitalized with all words being run together. Underscores shall be added for those columns needing to designate units. The units designations shall conform to the engineering standards. Any abbreviations used shall conform to the set of standard abbreviations as set forth in the abbreviations document. Why mix case with column names? Because this gives you the ability to spit out data directly to the user and still have nicely formatted column headers. Also it improves readability. Example: Employee_id, cFirstName, cLastName, iVelocity_mpm, intMass_kg
Indexes:Indexes shall be named for the table they are attached to and the purpose of the index. All letters shall be lower in case. Primary keys shall have a suffix of _PK. Foreign keys shall have a suffix of _FKx where x is a number. The number shall simply be incremental. Clustered indexes shall have a suffix of _IDX. All other indexes shall have a suffix of _NDXx where x is an incremental number. Only one suffix per index shall be appended. The application of the appropriate suffix shall follow the following hierarchy: clustered index, primary key, foreign key, other index. For example an index that is both a primary key and is clustered shall have a suffix of _IDX. Example: employee_PK, customer_IDX, employee_FK1, employee_NDX1, employee_NDX2 Triggers:Triggers shall be named by the table they are for and also for the type of trigger. All letters shall be lower in case. The purpose of the trigger shall be the prefix to the name. All triggers shall start with the letter t, a letter(s) designating the type, an underscore, and the table name. The type shall be designated as i = insert ,u = update ,d = delete. Example: ti_employee, tiu_employee, td_employee, tid_customer Defaults:Defaults shall be named by a d_ and a description of what the default does. All words should be run together and not separated by underscores. Example: d_zerovalue, d_username Rules:Rules shall be named by an r_ and a description of what the rule does. All words should be run together and not be separated by an underscore. Example: r_numberlessthan10 User Defined Datatypes:User defined datatypes shall be named by a ud_ and a description of what the datatype is supposed to standardize. All words should be run together and not be separated by an underscore. Example: ud_city, ud_autoincrement Stored Procedures:System level stored procedures shall be named by sp__ (that's two underscores) and a description of what the stored procedure does. All application level stored procedures shall follow a set prefix in place of the sp__ with a description of what the stored procedure does. It is a good idea to use a prefix that will also separate one application's stored procedures from another. All words should be run together and not be separated by an underscore. Example: sp__loaddata, csp_checktime, asp_employeetimereport Remote Procedure Calls:Remote procedure calls shall be named by an rpc_ and a description of what the remote procedure call does. All words should be run together and not be separated by an underscore. Example: rpc_getnextvalue Alerts:Alerts shall be named with a description of what the alert is for, what database the alert is for and what level of alert it is. Example: CUSTOMER Fatal Errors Tasks:Tasks shall be named with a description of what the task is, the frequency of the task, the level of the task, and what database it will be operating on. Example: ALL DATABASES Daily synch of development server Admin. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Back.. |