Grant Fritchey

Well, yes and no. I mean, the work I do as a DBA has changed. However, the amount of work has just increased and increased. Automation is all that lets me keep up.

Ha! Thanks. Happy to try to help, including bringing the occasional smile.

This is for SQL Server 2016, 2017 and Azure SQL Database.

Oh a little revolution now and then is a good thing. I agree. There was, is, a need to push back against the "relational everywhere for everything" approach that some people fall into far too easily. I'm in total agreement. Things are better now because we have solid choices. However, just like Big Data, NoSQL is a meaningless term. Especially now that the defined meaning is "Not Only SQL." That rips the guts out of it. Further, using the term doesn't provide us with good clarity in communication. "I want to use a NoSQL database" is a meaningless phrase. Someone I know compared it to cars. Let's say, we need something that cars can't do. So we call it a NoCar. Well, what kind of NoCar is it? Well, it goes under water and is self propelled and can carry people... You mean a submarine? No, it's a NoCar. NoSQL is the same.

HA!

So my suggestions we use a key-value store, a document store, or a true search engine means I'm making you come to me for column name changes? OK. Seems weird, but if that's what you got out of this, that's cool.

Was I a DBA? Yes. As a DBA, did I automate mechanisms so that developers could build their own stuff and we could automatically put it through CI, into QA, pre-prod and out to production... Yes. I don't care what you name the columns. Let's just agree that it should be clear and communicative and then, have fun.

However, I'm in 100% agreement with you. If anyone thinks that the way to get work done today is to stand in the middle of the road screaming "none shall pass", well, don't be surprised when you get run over. We are in the world of DevOps. Embrace it and succeed. Fight it and fail.

There's just no need to call it NoSQL.

My problem with it is that it's a silly term. "Not Only SQL". Well... OK, but what's the point? It just doesn't mean anything. Like I said, do we need a key-value store for our data? Great. Let's use it. But, does it matter if it has no SQL at all, or only some SQL or is fully SQL compliant? Nope. Does it do what we need, whether or not SQL is involved?

Sure thing. Happy to help.

Happy to help out.

The main reason to include it in the test was because the view was going to suffer more from compile times. I wanted to be sure that I told as complete a picture as possible.

I don't understand the rationale either. It is on a widely distributed checklist of performance tips though. I wanted to be sure there was some opposing information out there for people who bothered to do a search.

I absolutely wouldn't under normal circumstances. As I said at the top of the article, there is a performance "tip" that you should replace a view with a stored procedure to improve performance. It's silly, I know, but I felt compelled to prove how silly it was.

Comparing SELECT * to selecting all the columns, the network overhead will be just as bad either way.

The proper way to use SELECT is to limit the column list.

But it's not faster. And I do say that you should be limiting the SELECT list. I'm just arguing with a common, but wrong, performance tuning tip. Do a search. It's out there in multiple places and it's just flat wrong.

Nothing to correct. The article is comparing selecting every single column to using SELECT *. It's in response to a tip suggesting that even if you're selecting every single column, that will run faster than SELECT *. It doesn't.

Limiting SELECT lists is the right way to get things done. This small blog post was just correcting a narrow problem. It was suggested that listing all columns performs faster than running SELECT *. As shown, it doesn't. For real queries, absolutely, limit the columns in the SELECT list.

Excellent stuff.

In order to get the results to be consistent, instead of running them once or only a few times, I set up a PowerShell program that would let me run them thousands of times, then I took the average. There are a couple of background processes that could interfere, but because I ran them all so frequently, it averaged out much better than when I was running just a few small tests.

It's a lesson I knew already, but had to relearn it again (I'm slow sometimes).

And that's the correct way to do things.

Just adding a WHERE clause would change everything.

I was attempting to show a silly performance tip I've been seeing is horribly wrong.

I've been seeing a tip sheet on performance making the rounds that includes this piece of advice; listing all columns is faster than select *. It's horribly wrong. This short blog post was a response to that.

I'm trying to avoid being a shill, but one example would be a tool from my employer, Redgate SQL Prompt. It's a code completion tool for SQL Server Management Studio. It makes SSMS code completion work more like Visual Studio + Resharper. Another example would be SQL Sentry Plan Explorer. It's an improvement over the native SSMS execution plan viewer. Either of these is affordable and make you better at your job.

It's not just tooling. I've also had people complain to me that, while they really want to learn how to tune queries, paying for my book, SQL Server Query Performance Tuning, is not something they're prepared to do and their company won't pay for it either. Investing in making yourself better, through tools or knowledge, seems like the best way to get the better jobs and better pay, but maybe I'm just crazy (well, I am, but on this topic).

True, but once I had the conversion running through Powershell, it was really easy.