October 25, 2012 at 10:56 am
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.
October 25, 2012 at 11:02 am
Never seen it...looks completely pointless if you ask me.
October 25, 2012 at 11:08 am
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 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]
October 25, 2012 at 11:26 am
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.
October 25, 2012 at 11:28 am
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
October 25, 2012 at 11:32 am
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.
October 25, 2012 at 12:33 pm
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
October 25, 2012 at 12:40 pm
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.
October 25, 2012 at 12:44 pm
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
October 25, 2012 at 12:45 pm
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
October 25, 2012 at 12:53 pm
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.
October 25, 2012 at 1:00 pm
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