There Is a Magic Button: A Rant
There Is a Magic Button: A Rant
We database people have been hiding this huge secret for you from a while. It's finally time to reveal the magic Run Really Fast Button. It *definitely* exists.
Join the DZone community and get the full member experience.Join For Free
RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.
OK, guys. I think it’s way past time. A bunch of us have been keeping a secret from the rest of you. We know something that you don’t. I don’t think we should hide this secret from the world anymore.
Illuminati? Incompetents. Free Masons? I am one, so I already know all those secrets. Bilderbergers, Cthulhu Cultists, MKUltra, New World Order, Rotarians? All of these are nothing compared to the vast conspiracy that I’m about to reveal.
We need to just unveil the magic Run Really Fast Button.
We’ve been keeping that sucker a secret forever. It’s been tough. Every so often, some unauthorized person almost finds it or a “query tuning expert” (as if that was a real thing) tries to reveal it. But we’ve kept it secret from all of you.
You all know as well as I do that the supposed “experts” don’t make databases run fast by setting up the servers correctly on adequate hardware, or pick the right size service on our cloud provider. The “experts” never design properly normalized databases using good choices for the clustered indexes. The last damned thing they do is write decent T-SQL code that accounts for the fact that it’s a set-based processing language. All of that is just lies and propaganda.
No, the “experts” all just throw any kind of slop together that they want, any way that they want to. We just hit that magic button that we’re hiding from the rest of the universe.
I know what you’re thinking.
You think that Microsoft’s wicked cool automated tuning is going to save the day. They’ve got adaptive query processing that is going to change execution plans on the fly so that all the code you wrote into multi-statement, table-valued, user-defined functions is going to run really fast. They’ve got the ability to automatically add and remove indexes so that queries can run faster and they measure the performance for you so they know it worked. They’re even weaponizing the Query Store so that they can automatically fix plan regressions.
Sounds a lot like that magic Run Really Fast Button is exposed already.
However, you’re wrong, because the automatic tuning they’re supplying still isn’t going to fix the bad hardware you picked. It’s still not going to make sure you set your service to the right tier (that requires you to pay more, automatically, pretty sure most people will opt out). It’s still not going to be able to fix that database that was normalized by some Neolithic who can’t count past twenty without dropping their loin cloth. Finally, despite the fact of adaptive plans and automated regressions, you’re still writing code that no amount of automation can fix.
In short, people, we’re in an exciting time. Automation can take over so much of the mechanical drudgery of our jobs so that we can focus on the interesting problems. However, we have to first get beyond the fundamentals so that the automation can take over. That means the right hardware, the right database design, and the right code.
Let’s get on this.
Oh, and in case it’s unclear, there is no Run Really Fast Button. Seriously. No, I mean it. It’s not there (you’ll never find it anyway, just like you’ll never know all the proper settings to make DBCC
TIMEWARP function correctly).
Published at DZone with permission of Grant Fritchey , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.