Why not, instead of forensically trying to rebuild scripts for changes, just save your change scripts as you change things? Well, DB objects were put into vers

Why not, instead of forensically trying to rebuild scripts for changes, just save your change scripts as you change things? Well, DB objects were put into version control much later than other source files, so I wanted a way to guarantee that what's there in source control matches what we actually have in the database server. You're suggestion is that basically developers maintain the discipline of having changes in the files reflect what they run in the DB, right? I thought its significantly cleaner to have the database as the single source-of-truth and take everything from there. but it seems like they'd be a lot more readable Didn't quite get that part. The generated scripts are saved in one-per-file and reflect the name of the table/procedure/etc... that it contains. Isn't that basically what the 'best practice' way of doing it is? Merging is just to take the latest set of source control and bring your DB up to date with it. How do you handle version control? I'm certainly interested in a better way to do it.