3 ms·

The best plan for this today is the same as it was 20 years ago: write your change scripts in SQL. SQL is easy to learn, easy to read, easy to test, does exac

The best plan for this today is the same as it was 20 years ago: write your change scripts in SQL. SQL is easy to learn, easy to read, easy to test, does exactly what you tell it to with no surprises, and drops happily into version control. No tools required because tools can only possibly complicate things. The only reason the question you ask is in your brain at all is because of the trend 10 years ago to abstract away the database and declare it in configuration files elsewhere. There's no need to do that. The real thing is simpler, easier to comprehend, and guaranteed not to magically map your description of what you want into something different entirely.

thorin 11y ago
I think you're right. Keep a text file of your current schema in a vcs. This may be generated from a modelling tool, but you need a text file you can diff and log within the vcs. SQL isn't difficult to read, modify, test. Ensure you have dev and test servers. You must have someone in your team who is conversant with the db server(s) you target, preferably not an application programmer but someone focused on the database. There are many schemes to manage changes, but just store a alter and backout script of each change once in production works for me, give them a number and an order to apply. I'm managing schema for our product set of maybe 1000 db objects as well as doing some reporting, BI and some app dev and scripting. Just ensure that the team use the correct db and can rebuild easily to the trunk or release tag required and you should be fine.