• Stairway to DAX and Power BI - Level 14: DAX CALCULATE() Function: The Basics
• One Flyway Migration Script for Diverse Database Systems
• Disable or Enable All SQL Server Agent Jobs
• From the SQL Server Central Blogs - Timeseries Analytics Capabilities, and Azure Data Explorer (ADX)
• From the SQL Server Central Blogs - CDOT Bar Chart Makeover

• Migrate databases from SQL Server to SQL Managed Instance

Daily Coping Tip

Let go of self-criticism and speak kindly to yourself

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

Patterns and Potential Problems

I saw a post recently from a developer that needed to refactor and rename a table in a live system. The post describes a pattern for doing so and gives the steps taken, though not the actual code. I like the pattern overall, and I think it can work well in many situations. It's for a PostgreSQL table, so I don't know what restrictions might be different from SQL Server, but this type of pattern can work for SQL Server as well.

It also could be problematic. Using the famous "it depends", there could be issues with this pattern, depending on your workload and how your application is structured. The triggers in use could also be an issue in some environments, as they create an additional load.

The biggest concern I have with this pattern is the copying of the data. Likely this is something that always works on a developer's machine with a few dozen or even hundreds of rows of data. If this is millions, or tens of millions, the copy could end up taking substantial time. There is also the issue of changing data, with data being added or changed in the table, separately from being copied out. Depending on your locking and concurrency schemes, you could miss data.

Or you could just lock the table and cause issues for clients. Both things that might not show up in developer testing. The lesson here is that changes to big tables need to be tested in a big way.

This isn't to say the pattern is bad, but that you should be aware of the potential pitfalls and then develop mitigation strategies. One way to get around the data issue might be choosing a way of copying over new or changed data after the initial data movement, or maybe even a cleanup load later after the new table is online. There are many possible ways to mitigate issues, if you take some time to think about the potential issues and then come up with a solution.

When we are looking to make changes to our system, patterns are important to help us and others adopt the processes that work well. As we find and develop patterns, we need to ensure that we understand the strengths and weaknesses, and choose what's best for us, with mitigation strategies to get around the potential problems. There often isn't a perfect solution, and ensuring you and your team understand the limits of your chosen approach, helps ensure that we deploy code that not only works, but is deployed without causing issues.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums