Versioning Databases | Articles - Database
Get flash to fully experience Pearltrees
What started as a short brain dump is tuning in to a longer series of posts thanks to all the feedback and questions. In this post, I want to explain some of my thoughts on controlling objects like database views, stored procedures, functions, and triggers. But first... I haven't actually used a trigger in years. This isn't to say that triggers aren't valuable, but I've tended to shy away. Jon Galloway has posted a good example of what you can do with triggers .
Versioning Databases – Views, Stored Procedures, and the Like
Versioning Databases – Change Scripts
After considering the three rules and creating a baseline , an entire team can work with a database whose definition lives safely in a source control repository. The day will come, however, when the team needs to change the schema. Each change creates a new version of the database. In my plan, the baseline scripts created a schema change log to track these changes.
Continuing from the last post ( Three Rules for Database Work ), I wanted to drill into some database versioning strategies that have worked well for me. Caveats and Considerations As a preface, let me say there are many different strategies that can work. I'm not presenting the one true way .
Versioning Databases – The Baseline
Three Rules for Database Work
Some developers love working with relational databases, and other developers can't stand to touch them. Either way - if your application uses a database, you have to treat the database with some respect. The database is as much a part of an application as the code and the models inside the software. The convenience of a shared database is tempting. All developers point their workstations to a single database server where they can test and make schema changes. The shared server functions as an authoritative source for the database schema, and schema changes appear immediately to all team members.