mister.magoo (1/31/2015)
Storing currency values in a FLOAT is my least favourite, as I am constantly having to do stupid things like this
WHERE ABS(table1.column1 - table2.column2)<0.01
just to check for equality...
Wow. Pretty bad. That could become a computational least favorite for me. Fortunately, that normally doesn't happen for me.
What I really hate are the most common mistakes that really consume memory and disk space. My "favorite" is that it appears that much "automatic design" software used by front-enders create every integer column as a NUMERIC(18,0). Yeah... I like using 9 bytes instead of 4, 2, or even 1. Of course, storing phone numbers (etc) as NVARCHAR(anything) is insane. Another "favorite" of mine is VARCHAR(1).
What really lifts the stops on my steam valve is when you approach some "developers" on the subject, they sometimes get really snotty and give you that stupid retort about "Well, pre-optimization is the root of all evil". While that expression certainly isn't stupid and is painfully true, it's been inappropriately applied for such mistakes. They don't understand the difference between "pre-optimization" and "just" writing good code/proper design.
My other "favorites" are the subjects of indexing, DRI, and constraints. I recently had one 3rd party lead "developer" tell me that his database design, which includes no clustered indexes, no PKs, no FKs, and not even nullability constraints was all "best practice" because such things should all be enforced in the "business layer" and to make the database "portable". This idiot also doesn't see a problem with changing the name of a column every time it's stored in a different table. The really bad part is that this is supposed to be for a really high performance app that our company hired those moroffs for and I can't convince the 3rd party management (they don't employ a DBA or even a good database developer) nor our own ("Well, they wouldn't be in business if they were that bad") that all of this falls under the category of "worst practices" and that the app will be anything but high performance. Of course, when it fails to perform, they going to blame me for the "database performing slowly" at which time I'm going to redeliver the mountain of recommendations that I previously gave all of them one at a time in a rapid fire session of point blank high velocity pork chops. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.