March 6, 2012 at 9:23 am
Create a pattern, if your team mates can read it and understand it easy its a good pattern.
Returning two homonimal columns in a query is a nuisance, I agree but you remember to fit the pattern for the most common cases, there's no perfect pattern and its a bit of personal taste.
(it remember me a DB where all ids was named [ID] for any table, much more than a nuisance!)
I remember one time when we got a situation:
table:
HorribleLongName
HorribleLongNameSubDetail
HorribleLongNamexHorribleLongNameSubDetail
ToooooooLongNameTable
ToooooooLongNameTableSubDetail
ToooooooLongNameTablexToooooooLongNameTableSubDetail
HorribleLongNamexHorribleLongNameSubDetailXToooooooLongNameTablexToooooooLongNameTableSubDetail
It was a valid design but the relational tables got horribles names.
March 6, 2012 at 9:49 am
David, taking your example, TrailerActivityHeaderId and TrailerActivityHeaderTrailerNumber are not the names I would vote for. I would not name a table TrailerActivityHeader but TrailerActivity instead (Header is implied). Then its Id would be TrailerActivityId and the other column - just TrailerNumber. Notice how it is different from the name like Id, Number or Name. A generic rule would be that an identifier consisting of just one word is a suspect.
In any case, consistency should be the rule number one, the rest is judgmental.
March 6, 2012 at 9:54 am
MR@SD (3/6/2012)
David, taking your example, TrailerActivityHeaderId and TrailerActivityHeaderTrailerNumber are not the names I would vote for. I would not name a table TrailerActivityHeader but TrailerActivity instead (Header is implied). Then its Id would be TrailerActivityId and the other column - just TrailerNumber. Notice how it is different from the name like Id, Number or Name. A generic rule would be that an identifier consisting of just one word is a suspect.In any case, consistency should be the rule number one, the rest is judgmental.
See, I would use TA_Id or something to shorten it even more. Some may say it is less descriptive and may confuse someone new to the code and database, but then again, in database development you really have to have an understanding of the structure to even modify code. So, I think TA or TD prefixes are fine for columns in those tables respectively.
Jared
CE - Microsoft
March 6, 2012 at 10:09 am
See, I would use TA_Id or something to shorten it even more. Some may say it is less descriptive and may confuse someone new to the code and database, but then again, in database development you really have to have an understanding of the structure to even modify code. So, I think TA or TD prefixes are fine for columns in those tables respectively.
With this we would strongly but respectfully disagree. Becides, underscores carry no value when the camel case rules.
March 6, 2012 at 10:28 am
MR@SD (3/6/2012)
See, I would use TA_Id or something to shorten it even more. Some may say it is less descriptive and may confuse someone new to the code and database, but then again, in database development you really have to have an understanding of the structure to even modify code. So, I think TA or TD prefixes are fine for columns in those tables respectively.
With this we would strongly but respectfully disagree. Becides, underscores carry no value when the camel case rules.
No worries 🙂 Everyone has coding patterns that they like and should be consistent throughout an organization. I like underscores because they make readability easier to me. Some people like caps:
ProductNum
Product_Num
prodNum
prodNo
prod_no
Obviously the list goes on and on. I think the important thing is, again, to at least try and be consistent and at least somewhat descriptive. Make sure developers and members of the organization are aware of what's expected. Finally, balance between description and readability. Sure, it helps understanding to fully qualify a table name and column name, but it can make a large and complex query very hard to understand. If I have a simple query with 2 tables, Contract and Customer, I may use aliases C and Cu. If it was more complex and used more tables, I may change it to be contr and cust. I think we just have to always make a good judgement call based on the specific query.
Jared
CE - Microsoft
March 8, 2012 at 6:25 pm
jcb (3/6/2012)
Create a pattern, if your team mates can read it and understand it easy its a good pattern.Returning two homonimal columns in a query is a nuisance, I agree but you remember to fit the pattern for the most common cases, there's no perfect pattern and its a bit of personal taste.
(it remember me a DB where all ids was named [ID] for any table, much more than a nuisance!)
I remember one time when we got a situation:
table:
HorribleLongName
HorribleLongNameSubDetail
HorribleLongNamexHorribleLongNameSubDetail
ToooooooLongNameTable
ToooooooLongNameTableSubDetail
ToooooooLongNameTablexToooooooLongNameTableSubDetail
HorribleLongNamexHorribleLongNameSubDetailXToooooooLongNameTablexToooooooLongNameTableSubDetail
It was a valid design but the relational tables got horribles names.
By the same token, I hate table names with abbreviations in them because people are rarely consistent with their spelling. I also hate table names like "cus", "inv", and 'ta00001a5'. I'd much rather have an overly long but correctly descriptive table name.
That's just my opinion... not an argument.
--Jeff Moden
March 8, 2012 at 8:26 pm
Jeff Moden (3/8/2012)
jcb (3/6/2012)
Create a pattern, if your team mates can read it and understand it easy its a good pattern.Returning two homonimal columns in a query is a nuisance, I agree but you remember to fit the pattern for the most common cases, there's no perfect pattern and its a bit of personal taste.
(it remember me a DB where all ids was named [ID] for any table, much more than a nuisance!)
I remember one time when we got a situation:
table:
HorribleLongName
HorribleLongNameSubDetail
HorribleLongNamexHorribleLongNameSubDetail
ToooooooLongNameTable
ToooooooLongNameTableSubDetail
ToooooooLongNameTablexToooooooLongNameTableSubDetail
HorribleLongNamexHorribleLongNameSubDetailXToooooooLongNameTablexToooooooLongNameTableSubDetail
It was a valid design but the relational tables got horribles names.
By the same token, I hate table names with abbreviations in them because people are rarely consistent with their spelling. I also hate table names like "cus", "inv", and 'ta00001a5'. I'd much rather have an overly long but correctly descriptive table name.
That's just my opinion... not an argument.
Are we all too familiar with GL00100 or PA10000? 🙂 Damn you Great Plains!
Jared
CE - Microsoft
March 9, 2012 at 4:05 am
Jeff Moden (3/8/2012)
By the same token, I hate table names with abbreviations in them because people are rarely consistent with their spelling. I also hate table names like "cus", "inv", and 'ta00001a5'. I'd much rather have an overly long but correctly descriptive table name.That's just my opinion... not an argument.
I agree Jeff and I have an argument:
A meaningful horrible long name is prefearable to a pretty small cryptic one.
March 13, 2012 at 12:12 pm
MR@SD (3/6/2012)
David, taking your example, TrailerActivityHeaderId and TrailerActivityHeaderTrailerNumber are not the names I would vote for. I would not name a table TrailerActivityHeader but TrailerActivity instead (Header is implied). Then its Id would be TrailerActivityId and the other column - just TrailerNumber. Notice how it is different from the name like Id, Number or Name. A generic rule would be that an identifier consisting of just one word is a suspect.In any case, consistency should be the rule number one, the rest is judgmental.
Its a carry-over from an AS/400 application for which I was a SME on the Business Unit side of things. (Yes, I still remember several of the individual object names including KILLERG and everyone's favorite GMG.
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply