• Exploring Time Travel and Row Level Concurrency: Data Engineering with Fabric
• Microsoft Fabric and PySpark: Coding tricks to improve your solutions
• Casino night is back at PASS Summit 2024!
• From the SQL Server Central Blogs - Microsoft Purview GA menu’s
• The Definitive Guide to Azure Data Engineering: Modern ELT, DevOps, and Analytics on the Azure Cloud Platform

• Memory-Optimized Tables Memory

Cleaning Up Your Database

How many of you have objects in your database that aren't being used? What about something in a schema with a _old in the name? Or _2 or _3 or _delete? There is a lot of old, deprecated stuff I see in production databases. In fact, I've been somewhat amazed as I work with clients that many of the scripts we can build from a database with SQL Compare won't actually execute on an empty database because the script is full of broken code.

I also find plenty of DBAs that want to clean things up, but they don't. Sometimes they're afraid they'll break something, which is certainly possible. Sometimes they can never find the time. Often they might ask a manager, who usually says this isn't important and don't bother.

Is it worth it to clean up your databases?

Brent says no for old code. I say maybe for tables and code.

For a lot of code, Brent is right, your boss doesn't care and it doesn't necessarily help you. After all, it's in production now, and if it's being used, you're going to just create problems with a DROP. Where is the business value for removing old code (assuming it isn't being used)? What benefits do your clients get? Not you being happier there are less objects, but what is the business benefit.

That's the key. Is there a business benefit.  What I'd say is that if you have broken code, it needs to be removed. Because this does impact your software development process, especially when trying to match lower environments. For broken stuff, save the code in your VCS (you do version control database code, right?) and then delete this stuff from prod. It's broken.

Or fix it.

For tables, I would want to get rid of old tables as well. Why? Well, this is real costs in storage and potential reading of old data. If we moved data to table_old and someone decided they needed to read this for a report at the time, they might still be reading old data. I'd first rename these objects as object_delete_date with the date being a month away. Then I'd set a reminder for that date. On that date, bcp out the data, then drop the table. Period.

Two other things. First, make sure you know how to recreate the table (see the VCS comment above) and bcp in the data. Two, this is low-priority work. If you want to clean the database, know this is a long term, baby step process that will take months or years, and may never end.

Steve Jones - SSC Editor

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