To bring the discussion back to topic, what I take from the examples is this: Industry standards are there for a reason. Find out what they are and follow them. If you diverge from them, triple check that you know what you are doing.
Funny you should say that. A long time ago, I used to almost unquestioningly believe in "Industry Standards", "Best Practices", and a bunch of other things that all have the same ring to them.
I've been burned by so many of those that my stand now is "Before you do anything according to some standard or best practice, understand that even they may have been written by an idiot and adopted just because of how many other idiots agree. " To wit, my suggestion is that if you agree with them, triple check that they're actually based on good advice and that they actually do fit/solve your problem.
Yep... I know... sounds like "redeveloping the proverbial wheel" and, to a smaller extent, it is. But it's a whole lot better than being run over by a wheel that you don't actually know anything about other than it hurt like hell when it ran you over (voice of multiple experiences there). And, no... I'm not saying that all "standards" and "Best Practices" are bad. It just that, especially by the way they're written and, sometimes, who they're written by, you can't actually tell the good from the bad unless you do some serious studying and testing, especially in the world of software and the hardware it lives on.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
"Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)