To be honest, I'm starting to get really pissed off at people and their "new improved shinny bobbles". I've spent countless hours listening patiently and doing due diligence for things I don't know about before I open my yapper. When I'm finally equipped with the necessary knowledge and have suffered through interminable rhetoric and supposed proof of the need through some rather single minded demonstrations and then I prove that it can be done cheaper, faster, and better using tools that already exist, what do I get in return? The stupid deer-in-headlights responses of "Just because you can do something in SQL Server, doesn't mean you should" and the equally idiotic "That's so yesterday. You need to improve your skills and your attitude".
What people need to start doing is to do the same thing they're telling us to do and that's to learn something "new" and that's how to use the tools that are already available that already do the job no matter how old they may be.
I saw a great example of what I'm talking about just recently. I wish I kept the link because it was stupid. Even though not yet confronted with a request for it, I started to study a bit more about what Hadoop is all about. Now, I'm sure that Hadoop can do some really great things but, like I said, the example someone gave to justify standing up such a box and "learn something new" was to parse a log file that had a regular and predictable format to it. The key in the example was that all you had to know was what position the elements were in and it's easy to parse the log. Seriously? You want someone to stand up a box, go through licensing expenses, and learn a new language to do something that can be done even by the worst splitters in SQL Server?
Another example is where someone gave the edict that spreadsheets will not be made by SQL Server even though the ACE drivers do a fine job. Instead, they bought software that's not much more than SSIS on steroids, took them 3 years to figure out how to use, and has cost 350,000 USD in initial cost and now 5 years of maintenance fees.
Here's another... some folks at one company I help out made the great realization (and I'm NOT being sarcastic there, it's a great idea) that they shouldn't actually be processing the full snapshot of data that they get from a couple of companies every day. What they should be processing is the difference between today's file and the last file that they received. Some companies send a file every day and some do it once a week and others do it with rather unpredictable timing. They wanted to write a C# program and make it a part of a Web Service. To the best of my knowledge, they haven't put pen to paper, yet, and the "requirement" came about 2 months ago. I had a proof-of-principle up and running in 30 minutes and full production code up and running (it would find the latest file from today, and the latest file from any other day, automatically) in something less than 6 hours. It would take 800ms to pluck each file out of thousands scattered across multiple directories and then compared AND validated the 40 "fields" of data in both 129,000 line files AND load it into SQL Server in less than 9 seconds.
They're not using what I've done because "Just because you can do something in SQL Server, doesn't mean you should". Heh...the most advanced technology I used was the DIR command through xp_CmdShell (and that was NOT the showstopper because they use that a lot ).
Shifting gears, I loved the idea that MS came out with "CLR", more specifically, "SQLCLR". I was dreaming of the possibilities until someone brought me an "SQLCLR" that I had to disapprove of and wouldn't let it go to production. Before I could explain why and what the "work around" (in quotes for a reason), this guy raised holy hell and propped it up on a stick! "We'll just see about that" he said as he huffed out of my cube to get our mutual boss. Not only had he written something as an "SQLCLR" function that already existed in T-SQL, his code actually did it long hand instead of using the function built into his language of choice. It was an "SQLCLR" to do a modulo.
I'm no Luddite and I both love and embrace improvements especially if they're NOT mine... just make sure it's actually an improvement and not the fact that you don't actually know how to do your job nor use the tools that can already do the job that are already at hand. Learn that learning "new things" is sometimes learning about "old things".
The two things that I do agree with in the article is to work with each other and to do the necessary research even if you think you already know the subject. Do it for the company you're working for. They'll appreciate it a whole lot and the money you save them just might go towards your next pay raise or even the net shinny bobble that actually does make an improvement.
Remember, just because it's new, doesn't mean that it's an improvement.
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.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems
Create a Tally Function (fnTally)