April 5, 2010 at 8:04 am
Paul White NZ (4/4/2010)
You can't trust the database to enforce foreign keys anyway.😛 😀 😛
Considering that that bug has already been fixed, I'm not too worried about it.
- 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
April 5, 2010 at 8:19 am
GSquared (4/5/2010)
Considering that that bug has already been fixed, I'm not too worried about it.
Did you miss the (multiple) smileys, Gus?
Humour.
April 5, 2010 at 9:00 am
Great story, David, and I think that's a problem in many companies, including our vendors. They want features/enhancements in products I'm sure in order to meet bonus targets.
It says something about the way we compensate people that's an issue. We ought to somehow measure someone's work for compensation without them artificially "meeting" a goal in name only. I guess that's likely more of a moral issue than a business one.
April 5, 2010 at 9:04 am
Paul White NZ (4/4/2010)
You can't trust the database to enforce foreign keys anyway.😛 😀 😛
That's a horrible bug, even if it were unlikely to occur, that's the type of thing that should not come through an RDBMS test cycle. However, I would like to think those are extremely rare and that having RI in place actually does prevent issues.
The short-sightedness on the side of the business definitely occurs. They need things done, and I understand that. However I think the overhead of RI is worth it, especially as developers are transient, applications are not the only way to "get into" the database, and it's entirely possible that the DBA will be asked to "correct" something and could make a mistake.
Triggers (which I try to avoid) and RI are there are protection mechanisms, like security, and despite the overhead or hassles, are not something to be avoided.
I'll stand by my "design w/o RI is poor."
It's not because I think databases are so great. It's because we, as humans, are entirely too frail in our efforts.
April 5, 2010 at 9:07 am
Steve Jones - Editor (4/5/2010)
I'll stand by my "design w/o RI is poor."
May I substitute the word poor by the word wrong? 😉
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.April 5, 2010 at 9:09 am
Steve Jones - Editor (4/5/2010)
including our vendors.
As a rule of thumbs I think on a new version of a product as the fullfilment of whatever the vendor promised for the previos version 😀
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.April 5, 2010 at 9:27 am
Steve Jones - Editor (4/5/2010)
The short-sightedness on the side of the business definitely occurs. They need things done, and I understand that. However I think the overhead of RI is worth it, especially as developers are transient, applications are not the only way to "get into" the database, and it's entirely possible that the DBA will be asked to "correct" something and could make a mistake.
I agree. And I always argue for RI - but when you're being paid by the day, the final decision is not always yours. An amazing number of places mandate no FKs and NOLOCK on every query...:doze:
I'll stand by my "design w/o RI is poor."
Quite likely poor - but it depends on the business and the requirements. If they genuinely do not care about invalid relationships (sometimes justifiably) then the design is just fine.
BTW, I am a bit of an integrity zealot by nature - the code I post in answer to forum questions often features check constraints, defaults, foreign keys...just for the record. I am, however, also a realist.
April 5, 2010 at 10:11 am
I hate to get the black and white "wrong" in there. There is an exception to every rule, including mine. While I'd argue that 99.99% of the time if you think you don't need RI, you're wrong, there might be some transient stuff that matters.
I used to think that all "production DBs" needed full mode, but I found one that didn't.
April 5, 2010 at 10:25 am
Paul White NZ (4/5/2010)
Steve Jones - Editor (4/5/2010)
The short-sightedness on the side of the business definitely occurs. They need things done, and I understand that. However I think the overhead of RI is worth it, especially as developers are transient, applications are not the only way to "get into" the database, and it's entirely possible that the DBA will be asked to "correct" something and could make a mistake.I agree. And I always argue for RI - but when you're being paid by the day, the final decision is not always yours. An amazing number of places mandate no FKs and NOLOCK on every query...:doze:
I'll stand by my "design w/o RI is poor."
Quite likely poor - but it depends on the business and the requirements. If they genuinely do not care about invalid relationships (sometimes justifiably) then the design is just fine.
BTW, I am a bit of an integrity zealot by nature - the code I post in answer to forum questions often features check constraints, defaults, foreign keys...just for the record. I am, however, also a realist.
These are all some of the things that end up on my "caveat" list. As in - don't call me on these types of issues later and expect me to fix them for free as part of support. If you demand no DRI and crappy/none existent concurrency handling, I will end up fixing them for you, but I'm not doing it on my dime.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 5, 2010 at 10:33 am
Definitely this isn't something you fix for free. That's one I'd document as well if someone gave me a requirement of "no FKs"
April 5, 2010 at 10:44 am
Paul White NZ (4/5/2010)
david_wendelken (4/4/2010)
He didn't care if it worked on December 31st, he only cared that it could be announced to work on that date.Nice story. I would have laughed harder were it not so very true, and quite common.
It is too true - and personally I cringe when it happens.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 5, 2010 at 10:46 am
PaulB-TheOneAndOnly (4/5/2010)
Steve Jones - Editor (4/5/2010)
I'll stand by my "design w/o RI is poor."May I substitute the word poor by the word wrong? 😉
HAHA - I concur.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 5, 2010 at 10:52 am
Paul White NZ (4/5/2010)
An amazing number of places mandate no FKs and NOLOCK on every query...:doze:
I have seen the NOLOCK far too often and substantially more than the NO FK requirement. I am glad you lumped the two together - makes it look like the two are equally evil. 😎
BTW, I am a bit of an integrity zealot by nature - the code I post in answer to forum questions often features check constraints, defaults, foreign keys...just for the record. I am, however, also a realist.
I believe you - for the record. 😀
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 5, 2010 at 10:55 am
Matt Miller (#4) (4/5/2010)
These are all some of the things that end up on my "caveat" list. As in - don't call me on these types of issues later and expect me to fix them for free as part of support. If you demand no DRI and crappy/none existent concurrency handling, I will end up fixing them for you, but I'm not doing it on my dime.
Most certainly put it on their dime. However, without documentation it would be difficult to offload that cost. I like that you document it and then proceed. That is the way a project should be conducted.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 6, 2010 at 7:18 am
Paul White NZ (4/5/2010)
GSquared (4/5/2010)
Considering that that bug has already been fixed, I'm not too worried about it.Did you miss the (multiple) smileys, Gus?
Humour.
Nope. Just felt like chiming in on it anyway.
On the main point here: RI is a business rule, not a technical one, just like almost everything else that's done with business data.
- 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
Viewing 15 posts - 46 through 60 (of 70 total)
You must be logged in to reply to this topic. Login to reply