When refactoring, there needs to be a deprecation period or transition window. Not all apps will be able to apply the required changes all at once so the old schema and new schema need to run in parallel. Both the refactoring and scaffolding need to be deployed into production. The scaffolding ensures that the old schema and new schema are kept in sync. After a transition window, the original schema and scaffolding are removed and the refactoring is complete.
Scott then gives examples of refactoring techniques. These include: renaming a column, replacing a column, merging columns, removing a view, introducing a default value, replacing 1 to many relationship with an associative table, and introducing a surrogate key. In general, the techniques involve keeping the old schema, adding the new schema along with a trigger to keep the two schemas in sync. At a later date (after the transition period), the old schema and trigger are dropped.
Next Scott covers 6 ways to enable database refactoring.
- Accept the situation: Scott mentions that we need to accept the fact that the data is an important asset and that we should be able to change the data schema. The database should not be an anchor around our neck. Trivial things should be trivial to do. We have to be able to do what needs to be done and no tools will magically fix the schema for us.
- Teamwork: Developers need to learn data skills. They should understand the fundamentals of database modeling. They should know how to normalize. Also, DBAs need to understand design patterns. Operations must be flexible.
- Sandboxes: Developers need their own database instance or table space to work with. There needs to be development sandbox, project integration sandbox, demo sandbox, qa sandbox, and production.
- Configuration management: All system artifacts need versions( DDL scripts, test data, test scripts, source code, models, documents).
- Database Regression Testing: Testing should be at the interface to database (input/output), and also inside the database (stored procedures, views, triggers, constraints). Example, testing cascading deletes or null values.
- Encapsulate database access: not all apps will access the db the same way. Some will use Frameworks, some might use direct SQL, etc.
Then Scott covers the steps to deploy database refactoring:
- Sandboxes: Each team works in its own set of sandboxes.
- Deployment Process: Each team run regression tests, deploy code, deploy database refactoring, re-run test, back out if it does not work.
- Versioning issues: There will be different version of the database for different team sandboxes. Some are behind, some are ahead. Each database refactoring needs to be a script with incremental version numbers. There should be table in the database that keeps track of its current version.
- Deployment Windows: Operations can use windows to merge database refactoring scripts from different teams into 1 before rolling into production
Finally Scott leaves us with some parting thoughts. He mentions that if we can refactor application code we should be able to refactor database schemas. Refactoring a database is harder, but the tools are getting better. Don’t underestimate how difficult database refactoring is.
This presentation is available on InfoQ at http://www.infoq.com/presentations/ambler-database-refactoring