Has anyone seen a naming convention like this?

  • I just recently started work at a new location and, in getting familiar with their systems, I noticed that they are using a naming convention that I've never seen before.

    Let's say you have a table called "Customers" and then another table called "Addresses."

    Customers has columns named:

    CUS_ID

    CUS_FirstName

    CUS_MiddleName

    CUS_LastName

    CUS_BirthDate

    CUS_CreatedDate

    CUS_ModifiedDate

    Addresses has columns named:

    ADD_ID

    ADD_CUS_ID (foreign key)

    ADD_HouseNumber

    ADD_StreetName

    ADD_City

    ADD_State

    ADD_ZIP

    As you can see, the columns of each table are prefixed with an abbreviation of the table name. That's how all of their stuff has been currently, but we're starting to work on a new framework and all the documentation that they've developed before I got here has more and more of this stuff. I've tried to argue for more typical naming conventions, but they insist that this helps them identify relationships between tables. While I can sort of see this, it seems like all of this should be easily identifiable using standard conventions and properly aliased tables. Not to mention that I'm the one who's going to be writing the queries, not them.

    My question(s) is, before I totally throw this out, has anyone worked with naming conventions like this? Are there any advantages that I'm not seeing? This just seems totally asinine to me and results in completely unreadable column names, like AUA_CAE_DED_ID.

  • Never seen it...looks completely pointless if you ask me.

  • TheGreenShepherd (10/25/2012)


    I just recently started work at a new location and, in getting familiar with their systems, I noticed that they are using a naming convention that I've never seen before.

    Let's say you have a table called "Customers" and then another table called "Addresses."

    Customers has columns named:

    CUS_ID

    CUS_FirstName

    CUS_MiddleName

    CUS_LastName

    CUS_BirthDate

    CUS_CreatedDate

    CUS_ModifiedDate

    Addresses has columns named:

    ADD_ID

    ADD_CUS_ID (foreign key)

    ADD_HouseNumber

    ADD_StreetName

    ADD_City

    ADD_State

    ADD_ZIP

    As you can see, the columns of each table are prefixed with an abbreviation of the table name. That's how all of their stuff has been currently, but we're starting to work on a new framework and all the documentation that they've developed before I got here has more and more of this stuff. I've tried to argue for more typical naming conventions, but they insist that this helps them identify relationships between tables. While I can sort of see this, it seems like all of this should be easily identifiable using standard conventions and properly aliased tables. Not to mention that I'm the one who's going to be writing the queries, not them.

    My question(s) is, before I totally throw this out, has anyone worked with naming conventions like this? Are there any advantages that I'm not seeing? This just seems totally asinine to me and results in completely unreadable column names, like AUA_CAE_DED_ID.

    seems more like its a hold over from a legacy system from the early computing era that has inertia behind it and no one wants to change as it may require a major rewrite of application code.

    If you can change it i would. really looks like some old COBOL data storage to me.


    For faster help in answering any problems Please read How to post data/code on a forum to get the best help - Jeff Moden[/url] for the best way to ask your question.

    For performance Issues see how we like them posted here: How to Post Performance Problems - Gail Shaw[/url]

    Need to Split some strings? Jeff Moden's DelimitedSplit8K[/url]
    Jeff Moden's Cross tab and Pivots Part 1[/url]
    Jeff Moden's Cross tab and Pivots Part 2[/url]

  • I've seen it before, had to use it and hated it completely.

    It was the worst database design I've ever seen.

    It's pointless and will cause problems trying to understand what the columns are.

    Luis C.
    General Disclaimer:
    Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

    How to post data/code on a forum to get the best help: Option 1 / Option 2
  • Yes, I've seen it before. Was designed by a guy who got a PhD in Comp Sci in the '70s. He insisted that it had all kinds of readability advantages, and was absolutely sure that everyone else on the planet was wrong about it being less readable.

    Never could see any actual advantage to it.

    He also insisted on "tibbling" (i.e.: tbl_TableName, usp_ProcName), but, even worse, it also had the name of the company abbreviated onto the beginning of each object name. E.g.: If the company were "My Company", each object in every database would be prefixed with "MC_"; so "MC_tbl_TableName", "MC_usp_ProcName". Was all kinds of interesting when the company was purchased and changed names...

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Oh wow, that sucks. I knew a guy that prefixed every sproc that he designed with his name initials...he was a bit full of himself.

    So, the overall feeling that I'm getting is that a) this isn't completely unheard of and b) it's pretty old school thinking.

  • Yeah, I've seen that approach before too. It's supposed to make the code self-documenting or something. Any column can only ever be from one table. What a pain.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • This also makes no sense for relational purity. A foreign key is really an attribute of a different entity, so it shouldn't have a different prefix on the other end of a relationship.

  • To add some humor to it:

    What happens if you run a dessert-oriented business, and you have tables Customers and Custards? Do they both get "cussed" at on their column names?

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • I've seen it in a help desk application. If you're looking for a help desk app and you hate this naming convention stay away from HDAuthority from Scriptlogic.

    ---------------------------------------------------------------
    Mike Hahn - MCSomething someday:-)
    Right way to ask for help!!
    http://www.sqlservercentral.com/articles/Best+Practices/61537/
    I post so I can see my avatar :hehe:
    I want a personal webpage 😎
    I want to win the lotto 😀
    I want a gf like Tiffa :w00t: Oh wait I'm married!:-D

  • Never seen anything like that before. I have seen columns named prefixed with the data type, but that too can present issues should you ever need to rename a column in a table.

    int_CustomerID

    char_CustomerLName

    I typically follow something along the lines of the following for standards:

    Column names should be as descriptive and unambiguous as possible.

    Column names should NOT contain spaces or special characters.

    Column names should NOT be named after any SQL Server reserved keywords.

    Columns that have a foreign key constraint should be prefixed with an fk_ (e.g. fk_Loan_ID). This gives a quick visual indication of the relationship between the tables.

  • I have seen it at one of the Big 3. And I actually agreed with why they did it. They had so many disparate systems that you could aggregate data from, such that a primary key from an Oracle database was used as a FK into a table on SQL Server. It helped us to know what system that key was coming from.

    But really... if its an island system than it makes no sense.

Viewing 12 posts - 1 through 11 (of 11 total)

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