T-SQL Tuesday 146 – Frequent updates to SQL Server database objects

Reading Time: 3 minutes

For this months T-SQL Tuesday contribution I want to share some preconceived notions about frequent updates to SQL Server database objects.

I know that a lot of people have preconceived notions about doing frequent database deployments. Mostly due to the fact that I use to have a lot about them as well.

Before I go into this further, I must thank Andy Yun for hosting the first T-SQL Tuesday. of 2022. Andy has invited us to discussed preconceived notions we have had in the past.

You can find out more about the invite by clicking on this link about the T-SQL Tuesday 146 invitation or on the image below.

Preconceived notions about frequent updates to SQL Server

Years ago, I was responsible for a database environment that was high profile and had to meet a lot of auditing standards. I was heavily focused on the performance of SQL Server and its internals. Due to the fact that I was responsible for the uptime of the databases and their compliancy.

I must admit I was not a big fan of frequent updates to SQL Server database objects. Because I wanted the SQL Servers to perform as optimally as possible.

Plus, I had resolved issues caused by updates to SQL Server objects in the past and I I did not want to be resolving issues caused by them constantly. Something that I am sure that other SQL Server Professionals recognize.

In addition, I was more focused on SQL Server performance and its internals. So I was more keen on updates to objects that would improve SQL Server performance like indexes and statistics. Plus, nobody had explained to me the reasons behind the need for more frequent updates. Apart from mentioning the word Agile a few times.

Things changed

Everything changed when I got asked to look into implementing CI/CD for SQL Server. Due to the fact that I did my own research which answered a lot of questions I had about it. Including reading the well-known Continuous Delivery book by Jez Humble and David Farley.

From there, I did my first ever proof of concept using some third-party vendor tooling. After doing that everything changed. I went on to introduce processes to speed up frequent updates to SQL Server using more automated processes. Saving one company hours of work.

Afterwards, I went on to do other things and learn a lot more about how to use products like Azure DevOps and GitHub for Data Platform deployments.

Including one long-term assignment where I was lucky enough to be a SQL Server Product Owner. Where I worked alongside a team of outstanding SQL Server professionals. In addition, I have done customized Azure DevOps training days for Product Owners of various teams for a client as well.

Whilst I am talking about Azure DevOps, I will quickly plug the fact that I am co-presenting an Azure DevOps based Training Day at SQLBits 2022 alongside fellow MVP Sander Stad. I am mentioning it here because there is currently an early bird discount for SQLBits. Which is currently due to end on January 14.

Final words about frequent updates to SQL Server database objects

Anyway, I am glad I learned more about doing frequent updates to SQL Server database objects for so many reasons. It has opened up a lot of doors for me. Including becoming a Microsoft Data Platform MVP and a member of SogetiLabs.

In addition, as I mentioned in another post there is an increase in demand for Data Platform automation. Where companies expect it for a large range of Data Platform services.

Plus, more companies are expecting staff to use services like Azure DevOps to manage their daily work. Because I know more these days it makes things a lot easier when I start new assignments with clients.

Of course, if you have any questions or comments about this post feel free to reach out to me.