Naming conventions - ID Columns

  • Good morning all. I would like to ask a question regarding naming conventions, specifically involving ID columns.

    I would like some honest feedback from the group on this one:

    Between myself and one of my developers we have a fairly strong disagreement with regards to naming conventions; concerning ID columns specifically.

    One party feels that an ID column should always be named  'ID' while the other party prefers to standardize on a naming convention that specifies the nature of the ID column. The perfect example here would be a lookup table.  Lets say there is a table called (L_Status) - L = Lookup

    One party would call the ID Column ID while the other would name the column StatusID, another table might have ServiceClassID; naturally the table would be named (L_ServiceType).

    The reasoning behind this is presented as it is easier to follow and program Stored Procedures, Triggers, and the like; particularly when joins are involved as the columns are much easier to identify. That said the oposing party states that the SP can be just as easy to follow simply by looking at the logic or appending the table name to the statement (ie: L_Status.ID)

    Considering the above another argument is made that while the (L_Status.ID) method will lend some clarity it can still be a bit ambiguous when aliasing table names, not ALWAYS used in cases where there are no joins or joins with tables that do not have a 'ID' column and therefore maintaining an absolute naming convention will be touchy at best.

     

    I would like to hear the thoughts and practices of others here on this topic. I am sorry if this is in the wrong area. While I have been reading this forum for a while now this is my first posting and the 'rowid' comment reminded me to address this ever burning issue.

     

    <hr noshade size=1 width=250 color=#BBC8E5> Regards,Jeffery Williams http://www.linkedin.com/in/jwilliamsoh

  • I personally name the ID column something about the table name. I have my on conventions that I don't want to get into, but basically for table L_Status then the Surrogate primary key would be named StatusID.

    L_ServiceType, ServiceTypeID. etc.

    But I have other reasons, I have a ton of scripts, and procedures that use my strong naming conventions to generate code for me like Foreign key constraints, (Drop and create). Generate stored procedure definitions. etc.

    Ultimately it should be the DBA's decision, he/She has to maintain/Protect the database. if you don't have a DBA, then get the Boxing Gloves on.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply