4 ms·
We use the RedGate SQL compare tools [1] to compare our new schema to our old one and auto-apply the diffs to the production DB (this is done automatically by o
by louthy 7y ago
We use the RedGate SQL compare tools [1] to compare our new schema to our old one and auto-apply the diffs to the production DB (this is done automatically by our deployment process).
To reduce the chance of error we don’t destroy columns or tables.
Our application then has an update step which runs on startup for any data migrations (or new data additions), and then updates a version number stored in the DB. The data migrations are super rare.
This all means we can migrate from any past version to our latest one: because we have all previous schemas stored in git and n update functions in our app that can walk the versions
It’s worked reliably for over a decade and is pretty much entirely pain free
[1] https://www.red-gate.com/products/sql-development/sql-compare/ https://www.red-gate.com/products/sql-development/sql-compar...
- atwebb 7y agoI've got a fair amount of experience with it and the Change Automation tool they have. Both are fantastic products, the latter for certain scenarios over SSDT itself. Sounds like have had it sorted for a while, my main concerns are when it wants to rebuild certain tables when a simple sp_rename or other step would be sufficient.
- teddyuk 7y agoThis is such a common complaint!
- beart 7y ago> To reduce the chance of error we don’t destroy columns or tables. Does this mean you have a lot of unused tables and columns deprecated in the database?
- louthy 7y agoNo. It’s very rare that columns or tables are deprecated. It’s a very mature web app that basically just grows.