asked
Database versioning and source control
I have few queries on best practises of Database versioning. Suppose i have version as Major.Minor.Patch where Major: is the Schema compatible version with Application(i am planning to map it to major version of the application). And its not backward compatible. This means database version 5.x.x will not work with application version 4.x.x or 6.x.x. This way i feel that its easy to maintain the compatible application and DB. Minor: This can be used for individual DB changes. this should be backward compatible. This means that some table, column has been added which wont effect the existing application.(ex:new features) Patch: Backward compatible. Most of the bug fixes or changes in stored proc can go in here. Does this look ok? or can it be bettered? any inputs?
Was thinking of the exact same article! Can't think why I'd ever implement such a scheme, but good reference if you do!
We employ something similar. We have base SQL scripts to build the DB and "starting" data so that the devs can deploy every minute if they wish. For each version we store the upgrade script necessary to move from one version to another. This also give me time to review any changes.
Won't it be a too much of a headache if you are upgrading lets say from 1.1.2 to 1.3.1. How will keep track of the changes? Will you store sequential scripts or you will write a seperate script again?
I came across the article below. Maybe you will find it useful.
https://www.simple-talk.com/sql/database-administration/an-incremental-database-development-and-deployment-framework/
13 People are following this question.
