March 8, 2017 at 1:32 pm
Eric M Russell - Wednesday, March 8, 2017 1:16 PMI would never name a column 'authorization'. It would be something like 'AuthorizationDate' or 'AuthorizationCode', etc.
"Never"? Again, that was the business term they used for this. I'm trying to provide a good, working data model for the business to use, not just solely follow naming "rules". Sure, generally you want names to have specific rules and patterns, but if a certain term, and no other, has a specific meaning to that business, that's what I'll use. I guess it depends on which you consider more important: modeling your specific business for your company, or following generalized rules.
Besides, frankly this often seems to come down to what's easier for developers to use. I don't consider that particularly relevant to business needs.
SQL DBA,SQL Server MVP(07, 08, 09) "Money can't buy you happiness." Maybe so, but it can make your unhappiness a LOT more comfortable!
March 8, 2017 at 1:48 pm
I would never name a column 'authorization'. It would be something like 'AuthorizationDate' or 'AuthorizationCode', etc."Never"? Again, that was the business term they used for this. I'm trying to provide a good, working data model for the business to use, not just solely follow naming "rules".
I'm with Eric on this one. I would simply explain if necessary that reserved words need to be avoided. These things aren't just "rules" that somehow exist for their own sake. I've had too deal with way too much stuff because someone didn't follow the "rules." This would not fall under that, but it is still a good guideline to follow.
March 8, 2017 at 2:20 pm
Heh... I don't let users design the tables and I do design reviews with the Developers prior to them writing code against new objects as well as having a written/enforced set of standards so no real problems there. 3rd party stuff is frequently a pain in the knickers, though.
My biggest PO is when someone tries to make a column name like "IsNotActive".
--Jeff Moden
March 8, 2017 at 2:38 pm
ScottPletcher - Wednesday, March 8, 2017 1:32 PMEric M Russell - Wednesday, March 8, 2017 1:16 PMI would never name a column 'authorization'. It would be something like 'AuthorizationDate' or 'AuthorizationCode', etc."Never"? Again, that was the business term they used for this. I'm trying to provide a good, working data model for the business to use, not just solely follow naming "rules". Sure, generally you want names to have specific rules and patterns, but if a certain term, and no other, has a specific meaning to that business, that's what I'll use. I guess it depends on which you consider more important: modeling your specific business for your company, or following generalized rules.
Besides, frankly this often seems to come down to what's easier for developers to use. I don't consider that particularly relevant to business needs.
A business term called 'authorization' sounds more like an entity than a column; something like: "Our collections department processes more than 2,000 auto-debit authorizations daily." Columns within that table would have to refer to something like authorization ID, date or status code, and my opinion is that the choice of column naming should ultimately be about what makes sense to IT and the SQL developer. In my universe the business typically doesn't see column names, only reports and screens with labeled data.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 8, 2017 at 2:42 pm
Jeff Moden - Wednesday, March 8, 2017 2:20 PMMy biggest PO is when someone tries to make a column name like "IsNotActive".
and allows NULL as a possible value. I took the afternoon off one day when I found an existing consultant usingWHERE IsNotEnabled IS NULL
Wes
(A solid design is always preferable to a creative workaround)
March 8, 2017 at 2:55 pm
My biggest gripe is a database modeled after what was previously a collection of Excel sheets. It makes sense to one person in the accounting department, and is totally useless elsewhere.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 8, 2017 at 2:57 pm
RonKyle - Wednesday, March 8, 2017 1:48 PMI would never name a column 'authorization'. It would be something like 'AuthorizationDate' or 'AuthorizationCode', etc."Never"? Again, that was the business term they used for this. I'm trying to provide a good, working data model for the business to use, not just solely follow naming "rules".
I'm with Eric on this one. I would simply explain if necessary that reserved words need to be avoided. These things aren't just "rules" that somehow exist for their own sake. I've had too deal with way too much stuff because someone didn't follow the "rules." This would not fall under that, but it is still a good guideline to follow.
Ok. That's nothing I'm gonna cause ill will over, not worth it to me. Bigger battles to fight.
SQL DBA,SQL Server MVP(07, 08, 09) "Money can't buy you happiness." Maybe so, but it can make your unhappiness a LOT more comfortable!
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply