An agile DBA is committed to re-factoring database schema and code. This is not something we traditionally like to do, as a DBA. The reason is simple. Unlike code, making a change to your database has to be concerned with Data Loss. So, changing things like stored procedures, functions, etc. is not that difficult. But, when you change the underlying schema, and you alter already existing tables, because that is the correct design, the task is anything but simple.
As DBAs, we try to keep change to a minimum when it comes to the schema. We want our tables fully defined, with permissions and everything else figured out ahead of time. In fact, the more complete a database design is at the start of the project, the more we like it. In an Agile world, this is simply not possible.
Agile techniques take on a limited set of meaningful units of work, to be completed in a fairly short period of time, often extending from a week to a month. Everything is done within that period, from the database design to the application code. The features are complete, and the next period begins. Using this pattern, the database evolves one feature at a time. The downside of this methodology is that you cannot see things in your database that may be re-used across multiple features until you begin working on the next one. When that happens, you either continue with your existing schema, or create a new one that fulfills the needs of your original requirement, and your new requirement. This is re-factoring.
Although there may be more work when designing a database in this fashion, because you have to modify things already in use, you will find that you get a better product in the end. When you try to create the database completely up front, it is rare that you really get it right, or meet all the needs in the best fashion. If you are able to make changes, and this is a mindset you have adopted, then you will find the additional effort to be less onerous than trying to fit things into a design that doesn’t really work.
A good example of re-factoring might be when you have a table with a large text field for notes. After a time you find there are many queries being run to search for a word or a phrase contained in the notes, which should have been a separate field in the original table. These are readily re-factored into a separate column at a later time.
Re-factoring is a skill every DBA needs to learn. Working with an Agile team, it is essential.
Cheers,
Ben