Jeff Moden (10/8/2013)
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. 😀
While I don't necessarily disagree with the discussion - it's important to remember that complex is often a point of view. Jeff , what you call simple took me 6 months of decomposing to even comprehend the first time I saw it. The tally table tricks, quirky update, and command of BCP is stuff I simply just don't use enough to stay as good on those as I'd like to. Simple is fine thing to strive for, but you can't always code to the lowest common denominator on the team.
I think there needs to be a rationalization of what tools to use, but someone showing up with new skills and tools MIGHT actually have a point every once in a while. Shutting down to new options can be just as problematic as tilting after the latest shiny windmill on the horizon.
I think it's okay to try out new things: just be clear about it, and make sure everyone who might have to come in contact with it is socialized in the new tool and knows how to support it OR to shoot heavy thing in your direction when it does break.
----------------------------------------------------------------------------------
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?