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. Here are three rules I've learned to live by over the years of working with relational databases. 1. Never use a shared database server for development work.