Schema Naming Conventions

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 7,2000 » Strategies » Schema Naming Conventions

Schema Naming Conventions

Rate Topic

Display Mode

Topic Options

Author

Message

ckempste

Posted Wednesday, July 11, 2001 2:13 AM

SSC Eights!

Group: General Forum Members
Last Login: Tuesday, July 31, 2007 8:20 AM
Points: 885, Visits: 1

Not again you sigh... :)

Well, its on for young and old and im in the thick of it yet again. Table and column naming conventions are what I am after as far are recommendations and tried and tested schemas. I have gone for the following for sometime now:

Tables : name as required to represent the business, eg. trade
P.Keys : post-fix with _id, eg. trade_id
F.Keys : the joining column is listed as part of the column name

eg. traderto_trade_id this example means the table “trade_rto” joins to “trade” over “trade_id”

The first portion (column prefix) should shorten to <= 8 characters in length with no spaces or underscore characters. For example:

Employer => emp_<column name>
Employer_site => empsite_<column name>
Organisation -> org_<column name>

The 8 character restriction is for the tables prefix, not the entire length. Even so, the entire length should not exceed 30 characters if possible.

Another schema design we have in another app database uses the following:

The other uses a slightly different approach. The only difference in this method is the naming of columns, which is especially evident in the key-column referencing. For example:

Training_Product ----------------------- Course
Training_product_id (pk) Training_product_id (fk)

In this case, as the training product table is the parent, all other referring tables use the same primary key column name for the foreign key column name. This is a common scheme, but unfortunately does not allow a developer to “follow the relationship model” from one table to the next and thus, for large data models, can be time consuming when creating large complex queries. Another problem is that extensive use of table aliasing is required in such a scheme.

I have also heard of schemes where the data type of the column is in the naming of the column. This seems very strange and something I wouldnt like to explore for a variety of reasons.

What I havent gone into is issues of replication, and inter-related schemas with the same table names.

Ideas?

Cheers

Chris

Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"

Post #565

Andy Warren

Posted Wednesday, July 11, 2001 6:33 AM

SSCertifiable

Group: Moderators
Last Login: Tuesday, June 11, 2013 6:34 AM
Points: 6,463, Visits: 1,388

Im definitely against any data type desc in the column name. Where I work, we have an app that uses "foreignkey" for all the foreignkey cols. Guess what it calls the primarykey cols! It's not a bad system. Overall, I like to use the colname of the primarykey as the col name of the foreignkey column.

No spaces in object names! No spaces in object names! No spaces in object names!

Andy

Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter

Post #19953

K. Brian Kelley

Posted Wednesday, July 11, 2001 12:53 PM

Keeper of the Duck

Group: Moderators
Last Login: Yesterday @ 7:47 AM
Points: 6,584, Visits: 1,796

Where I work, we follow a naming convention to what Michael Hotek proposes. Here's the link to the article on his site:

http://www.mssqlserver.com/articles/naming_conventions_p1.asp

K. Brian Kelley
bkelley@agfirst.com

K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of Introduction to SQL Server: Basic Skills for Any SQL Server User
| Professional Development blog | Technical Blog |

LinkedIn | Twitter

Post #19954

Steve Jones - SSC Editor

Posted Wednesday, July 11, 2001 5:13 PM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 5:09 AM
Points: 31,526, Visits: 13,864

I developed a standards document similar to Michael Hoteks, but more in line with my habits. I am a fan of abbreviations and Proper case, but I have seen some good arguements to use more descriptive names.

I have an article (not posted yet) on naming standards, but basically here are mine:

Tables: descriptive name of data being stored (customer, products, etc.). Suffix of _lu for lookup tables.

Columns:Use standard abbreviations (set forth in company document), proper case. Ex, EmpID, CustID, ProdSKU, OrdDt

PK: <table name>_PK

FK: <source table>_<dest_table>_FK. If more than one FK, then FK1, FK2, etc.

Indexes: <table name>_IDX for clustered index. If this is PK, PK rule takes precedence. Non clustered indexes are <table name>_NDX1, _NDX2, etc.

Triggers: Haven't done much with instead of triggers, but my standard held over from v6.x is tr<purpose><table name>. Ex: triCustomers (insert trigger for Customers table), triuEmp (insert, update trigger for Emp).

Defaults: df<name>. descriptive name

Rules: don't use them. Suggest r_

User Defined Datatypes: Not used

Stored Procedures:
sp<purpose><descriptive name>. Ex. spIns for inserts into single table, spAdd for inserts into multiple tables. I have a series of 12 or so purposes spelled out in the document.
For DBA procs, dbsp<descriptive name>

Steve Jones
steve@dkranch.net

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #19955

Gopal Sharma-464186

Posted Thursday, February 19, 2009 7:07 AM

SSC Veteran

Group: General Forum Members
Last Login: Wednesday, September 19, 2012 1:54 AM
Points: 253, Visits: 23

We follow pretty much the same as Steve mentioned, only significant difference being the stored procs. For stored procs we use p_ .
For user defined procs, we should always start (depending on convention) with anything but sp coz all system procs are sp and SQL Server it seems takes longer (prob fraction of second but yes :)) to locate our proc starting with sp. we also prefix purpose by few common operations we do ...viz populate/clean/verify/move follwed by actual purpose in short.

Thanks

Post #660269

Roy Ernest

Posted Friday, May 29, 2009 8:11 AM

Hall of Fame

Group: General Forum Members
Last Login: Thursday, June 13, 2013 11:29 AM
Points: 3,280, Visits: 6,626

Gopal Sharma (2/19/2009)

Gopal, it is not sp that is the problem. It is sp_. There is a big difference between sp and sp_. sp_ are system procs.
As for the naming convention, we use more or less the same as Steve mentioned. The difference being for index it will be idx_tablename__columnName. Just one under score additional.

-Roy

Post #725831

« Prev Topic | Next Topic »

Permissions