A Fine Slice Of SQL Server
Andy Brownsword has it together:
It’s a legacy pattern, and thankfully it’s rare to see these in the wild nowadays.
The legacy
OUTER JOINsyntax (*=and=*) which used to accompany these was deprecated, and finally removed in *checks watch* SQL Server 2012, so that’s one less reason to see the aging syntax.
Every time I see this format, I despise it. Andy explains exactly why. We’ve had better options for more than 30 years, yet people still choose to write code this way.
Leave a CommentBrent Ozar knows when a query is going to be bad:
I open it up and the first thing I see is a comment with a changelog showing a long list of dates and author initials.
Oh I know, you think documentation is a good thing, but:
Read on for the reasoning. Admittedly, this is a pretty good sign of pretty bad code.
Leave a CommentVlad Drumea comes up with a list:
This is my list of “main suspects” that make me instantly think a query is bad as soon as I see at least one of them.
Note, this is just based on the query text alone, seeing the execution plan is an instant confirmation.
Now, without further ado and in no specific order:
Click through for the list. There are some good items on it.
Leave a CommentRebecca Lewis answers a question:
This post is part of T-SQL Tuesday #200, hosted this month by Brent Ozar. The prompt: “When I’m looking at a query, I bet it’s bad if I see ____.”
Easy. I didn’t even have to think about it. When I open a stored procedure and see a function wrapped around a column in the WHERE clause, I groan. Out loud. Because more often than not, it means the predicate is non-SARGable, and non-SARGable means your indexes just became very expensive shelf decorations.
That is a pretty good answer, yes. Almost nothing good comes from wrapping columns with functions in the WHERE clause or as part of a join criterion.
Leave a CommentKoen Verbeeck wraps up another T-SQL Tuesday:
A good week ago I hosted the monthly T-SQL Tuesday blog party. I invited the community the blog about the idea of what would happen if we would need to go back on-premises, after a good decade of cloud computing. What would you need to do? How do you plan for this? What are the skills you might need to (re-)learn? You can find my take on this here, where I’m telling my junior colleagues that troubleshooting issues on-prem is more challenging, because it’s possible you need to go way down, all the way to Kerberos, SAN and DNS issues.
Click through for the contributions.
Leave a CommentAndy Brownsword reminds us that it’s still the same animal:
Cloud solutions have sliders which magically reduce downtime, performance issues, and account credit. When you build it, infrastructure and platforms are your challenge, and you get one shot to right-size it. Capacity, resilience, capabilities. They’re your challenges to solve. There is no
cakeslider.It’s the capabilities I want to consider here. The capabilities we have available to us day-to-day. Potentially two opposing sides:
To summarize things, everything is awful, just as it always has been. Granted, that may not be how Andy would summarize things, but that’s why I get those big Curated SQL bucks.
Comments closedAndy Leonard shares some thoughts:
Right-sizing didn’t always work out the way some clients were led to believe it would.
In nearly every instance, the right-sizing argument was presented (sold) as the solution to over-provisioning, or purchasing hardware to serve peak loads. The classic example was a US income tax service that needed more and faster compute available to meet increasing demand starting in late January and peaking in mid-April each calendar year. After mid-April, hardware that was beefy enough to handle that peak load sat mostly idle for the next 9 months.
I don’t think I’ve ever worked for a company where this scenario really made sense. Even in the e-commerce company where a sizable fraction of our total annual revenues happened over a 5-day period, the load was still significant enough the rest of the year that we made good use of our on-premises SQL Server hardware.
Comments closedDeborah Melkin muddies up the waters a bit:
My first reaction to this sentence was: Oh look, he assumes that everyone is in the cloud…
My next reaction was: Oh look, he acknowledged that maybe everyone isn’t in the clouds in his follow-up examples.
Since the cloud was introduced, the assumption was always going to be everyone will moving to the cloud. “You’ll be behind if you don’t learn the cloud,” they said. Then as people either moved or started looking into moving their databases, they realized they just couldn’t – whether it was due to missing features, higher than expected costs, etc. There was always some reason.
Click through for some of the challenges and realities of organizations where certain cloud-first or cloud-only services would be a major challenge, versus other services that are typically easier to deal with.
Comments closedMike Donnelly has some tongue-in-cheek responses:
There are some serious angles to this topic, and I have had conversations with people at conferences who are doing a remigration from the cloud, but it feels like the exception not the rule. It is interesting to think about. I spent most of my career working with on-prem SQL Server, but there was a period of about 10 years (the consulting years) where I didn’t touch anything that wasn’t in the cloud. The past several years have been working in a hybrid environment, but most of the work has been moving things to Azure and Fabric. Koen has some prompts for what our blog posts could be about, but rather than dive deep into any one thing I’m going to go with the blog writer’s best friend – a top 10 list.
The funny thing is, in my time as an on-premises DBA, I never dealt with hardware and didn’t have access to the server room.
Comments closedBrent Ozar lists three pain points:
For T-SQL Tuesday #199, Koen Verbeeck posed an excellent question: if your company moved up to the cloud, but after migrating, had to come back on-premises, what would be the big problems?
I’ve had clients in this exact situation! Here are some of my favorite gotchas from those experiences.
Click through for those three. I’d say that the first one is a major issue and will probably be one for the next couple of years—unless the bottom drops out sooner than I expect and we suddenly have a rush of used hardware from highly unprofitable organizations hit the market.
Comments closed