Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Schema Naming Conventions Expand / Collapse
Author
Message
Posted Wednesday, July 11, 2001 2:13 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!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
Posted Wednesday, July 11, 2001 6:33 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: 2 days ago @ 9:01 AM
Points: 6,705, Visits: 1,680
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
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #19953
Posted Wednesday, July 11, 2001 12:53 PM


Keeper of the Duck

Keeper of the Duck

Group: Moderators
Last Login: Thursday, April 03, 2014 10:06 PM
Points: 6,621, Visits: 1,851
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
Posted Wednesday, July 11, 2001 5:13 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
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
Posted Thursday, February 19, 2009 7:07 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC 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
Posted Friday, May 29, 2009 8:11 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Thursday, March 13, 2014 9:27 PM
Points: 3,283, Visits: 6,670
Gopal Sharma (2/19/2009)
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

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 »

Add to briefcase

Permissions Expand / Collapse