CODEWITHSUNDEEP
databaserefactoringproduction-environment
PhD
PhD

Reputation: 11334

Best practices for refactoring a database in production?

I'm currently working on a project where our product at the current version is deployed at more than one client site. More often that not we test and scrap (a.k.a. refactor :) the DB design in our dev/test environment. It's not possible to keep track of every incremental change to the DB to create the corresponding 'migration files'. And now when we are satisfied with a DB design (relatively stable) we need to update the production DBs to the current state.

Our system in production can't just be issued a DROP/CREATE SCHEMA command to update the schema (think of the jobs that would be lost, mine included :) So we land up either writing MySQL dumps or application wrappers to backup the data and re-enter it into the DB. Quite cumbersome, especially when multiple 'clients' are NOT at the same DB version. It's quite cumbersome to write one for every version that the clients have.

So what are some of the best practices that you employ to refactor databases in production especially when you CAN'T just delete that data but need to re-enter it and have the system seamlessly continue after some 'downtime'?

If it's of any use the backend is Java/Restlet and MySQL

Upvotes: 2

Views: 944

Answers (1)

user438639
user438639

Reputation: 46

You can use database refactoring patterns described in the book Refactoring Databases and see the website for database refactoring http://databaserefactoring.com/ . Using the migrations approach you don't need to drop and create the database. Tools such as [dbdeploy], [dbmaintain], [ibatis migrator], [liquibase] etc can help you here.

Upvotes: 2

Related Questions