logitestus (10/8/2013)
I run into this type of problem everywhere I have worked. Someone states "this is the way to do it" because they saw X% faster performance. As my group's resident "expert" on SQL, I have had to teach multiple "lunch-n-learns" on SQL performance tuning. Before this everyone based their SQL perf on how fast the query was (and sadly some still do). The problem with this was/is the test set of data is maybe 100 rows at best. In production we get at least 10-100 times that. Then they wonder, why isn't my query/view/stored proc running faster.
Very well done on the "lunch-n-learns". It's not only a powerful way to teach people but its also a way for folks to get closer to the DBA and more easily understand the reasons for our individual and shared mantras.
I also have to agree with Jeff on the hodge-podge of technologies people use. A few of our customers use a Python-scripted tool which utilizes a .Net 1.1 custom executable (source no longer exists) to import data from a flat file to a SQL 2005/2008 database. The Python experts always say its the .Net or the database. The .Net folks blame Python or usually the database. I've been forced to become, at least slightly proficient, in all of those technologies just so I can prove that its a combination of all 3.
While everyone is blaming everyone else, my normal fix for such a hodge-podge of cruddy code is to simply can it all and start over. While that sounds a bit spooky, I've frequently found a total rewrite to be a quicker solution than to try to patch already horrible code. It also stops the silly bickering by the other folks because not only has the problem been fixed, but it's also not their code anymore.
They can't shoot pool if I take their stick away. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.