question

jctronicsshiva avatar image
jctronicsshiva 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?
databasedatabase-designschemaversion-control
3 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Was thinking of the exact same article! Can't think why I'd ever implement such a scheme, but good reference if you do!
0 Likes 0 ·
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.
0 Likes 0 ·
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?
0 Likes 0 ·

1 Answer

·
sp_lock avatar image
sp_lock answered
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.