It’s time to do the round up of this month’s T-SQL Tuesday entries. It was great to see so many people responding, including at least one new participant. I think there are a lot of kindred spirits here, as in we’ve all felt each other’s pain. (I know that I personally can relate to way too many of these things.) And I truly enjoyed reading everyone’s post.
So let’s go through the run down:
- Aaron Bertrand (t) – https://sqlblog.org/2022/07/12/t-sql-tuesday-152-soapboxing
Aaron decided to follow on the trend of some of his more recent posts. He jumped on his soapbox about leading commas and the excuses that people use to justify them as valid formats, when they really just make things unreadable and create other headaches since they don’t solve the problems they are supposed to.
Andy likes to rant and he let us know how really feels about ORMs (object-relational mapping frameworks). He mentions things like trying to be RDBMS agnostic, naming issues, not scaling. Essentially, he chalks the problems to developers making assumptions about how everything worked and just accepted things at face value. Personally, I think we all feel his pain.
Unsurprisingly, Andy Levy’s summary is in the same vein as Andy Yun’s post. Because this Andy talks about the consequences of decisions, including performance issues caused by ORMs (sound familiar?), applying all the DTA recommended indexes at once without testing, etc. It all comes down to understanding the consequences.
- Chad Callihan (t) https://callihandata.com/2022/07/12/t-sql-tuesday-152-a-rant/
Chad pulls out a rant about assumptions about whether databases are being used and whether you can just get rid of them. You should clean up after yourself but be careful when cleaning up after others. Great reminder!
- Deepthi Goguri (t) – http://dbanuggets.com/2022/07/12/t-sql-tuesday-152-rants/
Deepthi has a few things to say about database server migrations and the “fun” that happens when server names or IP addresses get hardcoded in places like SSIS packages, Linked Server connections, etc. so everything fails when the switchover is made. Luckily, she has a suggestion to help prevent the problem in the first place.
- Eitan Blumin (t) – https://eitanblumin.com/2022/07/12/ssdt-which-version-of-my-database-was-deployed/
I really enjoyed Eitan’s post, partly because I feel like his rant goes along nicely with mine. Eitan talks about making sure you know what version of your database was deployed. He has a lot of great examples about how you can version your database projects and use them to manage those deployments, along with other suggestions for versioning database releases. I may be bookmarking this to share with others.
- Gerard Jaryczewski (t) – https://sqlrebel.blogspot.com/2022/07/be-ready-to-change-your-mind.html
When Gerard posted back to my invite, he said he was bringing beers and chips to the party. He also brought a great introspective post about being ready to change your mind. He shares how he was about to write an angry rant response to a line in a blog he read but his argument changed as he thought more about it. I really appreciated his thought process on this and hope you all do too.
Speaking of beer, Glenn gave us a two-for-the-price-of-one. The first rant is that DBAs need to understand the hardware that their databases are running on. Simple things like a processor can make a difference for performance and scalability and a production DBA should be able to know whether their server hardware can handle the load. The second is if the database is going to be blamed by default for all performance issues, DBAs should be proactive and make sure they can say whether or not it’s true when the time comes. Luckily, Glenn has an amazing set of scripts (the Diagnostic Information Queries) available for us all to use.
- Greg Moore (t) – https://blog.greenms.com/2022/07/12/t-sql-tuesday-152-my-rant/
Greg decided to go with an “I Told You So…” story. It’s a tale of what happened when a developer didn’t listen to him about how SQL Server doesn’t always sort rowsets the way you think, so even if you only have one row, you may still want an ORDER BY in your query. Y’know, just in case another record gets added…
- James McGillivray (t) – https://jimbabwe.co.za/2022/07/13/t-sql-tuesday-152-theres-only-one-data-model/
James took advantage of the time zones and got his post in just in time. He pulled out his soapbox to talk about why he is so passionate about one data model per business area to make sure that all end users are consuming consistent and accurate data.
- Josh Darnell (tr) – https://joshthecoder.com/2022/07/11/putting-files-in-a-database.html
Welcome to the T-SQL Tuesday party, Josh! In his first contribution, Josh shared a “that one time at that client” story. All of the images for the application got stored in a single table in the database. From deployments to storage to performance, this just sounds painful.
My invitation apparently was very timely for Ken. He decided to share his strongly held opinion about proof of concepts (POC). He’s seen too many POCs go straight to production so if you aren’t following your own standards and best practices, you’re doing them wrong.
- Kevin Chant (t) – https://www.kevinrchant.com/2022/07/12/t-sql-tuesday-152-save-your-colleagues-from-a-database-restore-nightmare/
Kevin is taking advantage of the invitation to give us his opinion and is using it to give public service announcement. He reminds us all that you must regularly test restores of your database backups. It saves everyone’s time, money, and jobs. It also saves us the pain of a 27 hour restore nightmare.
- Mala Mahadevan (t) – https://curiousaboutdata.com/2022/07/12/t-sql-tuesday-152-thecrazyloginclient/
Mala gives us her opinion about a former client who had a crazy login policy. I don’t think I can properly summarize it here so you’ll have to read it for yourself. But I’m with her – there’s no “it depends” that can justify this scenario!
Rob is more than a little frustrated by sargability. More specifically, he’s frustrated by creating indexes to take advantage of sargable predicates and improve query performance to only be stymied by people who don’t know how to write queries to take advantage of them.
- Shane O’Neill (t) – https://nocolumnname.blog/2022/07/12/t-sql-tuesday-152/
Shane also joins Andy Levy with his opinion on ORMs and encounters the exact same problems. He coins the phrase “DUh SQL” to refer the generated SQL code. As Shane says, everything just works until it doesn’t. Again, I think we all feel his pain.
- Steve Jones (t) – https://voiceofthedba.com/2022/07/12/t-sql-tuesday-152-it-depends/
First, I want to thank Steve again for letting me host this month and for all he does keeping T-SQL Tuesdays going! And now I can thank him for his entry talking about how the devil is in the details when it comes to automating database deployments. He takes a look at how you move past the “it depends” stage into actions that make sense for what you’re trying to accomplish and actually solve your problems.
- Tom Zika (t) – https://straightforwardsql.com/posts/whats-in-a-name/
Tom is building on his entry from last month to rant about application names. To be more specific, he firmly believes you should name your application as part of the connection strings to make it easier when monitoring for performance. It’s a small thing that can make a difference.
- Tracy Boggiano (t) – https://tracyboggiano.com/archive/2022/07/t-sql-tuesday-152-it-depends/
Tracy saved her “It Depends” for the two different types of managers and the access they may think they need or once had versus the access they actually do need. There may be a reminder about making sure your security groups are kept up to date somewhere in there too.
And as for me: my contribution is about how you have to have a “source of truth” for your database. You need to be able to guarantee that you know what is supposed to be in your database to make sure new installs and upgrades for any and all versions are successful at all times.
As I said, there were a lot of great contributions this month. Thanks to everyone who participated! If I missed your post or I need to make any corrections here, please let me know!
Looking forward to seeing next month’s topic. If you are interested in learning more about T-SQL Tuesdays, please check out the website for the history and the links to past invitations.
Deb the DBA 
2 thoughts on “T-SQL Tuesday #152 – Round up”