5 ms·
Based on the experience of co-workers (and my own limited dabbling), you are right that version control is (and should be) used for stored procedures just as it
by RussianCow 8y ago
Based on the experience of co-workers (and my own limited dabbling), you are right that version control is (and should be) used for stored procedures just as it is with application code. The problem is that there isn't a lot of tooling that isn't language- or platform-specific to help maintain these things in the long run. So DBAs tend to write and maintain their own collection of homegrown scripts for deploying changes to the DB (or worse, do it by hand).
I'm sure some companies have this figured out, though, so YMMV.
- nathanaldensr 8y agoI certainly figured it out at several jobs: - Scripts are numbered for quick order determination by humans (e.g., 0001-initial-schema.sql, 0002-create-foo-table.sql) - A scripts.json file containing an array of string filenames declares the exact order of scripts, just in case numbers are shared for some reason (say, two branches being merged at the same time with a new script in them) - A custom PowerShell module knows how to read scripts.json and the files and execute the changes - When possible, all scripts are executed transactionally by the CI tool (some commands in some RDBMSes can't be executed in transactions, however) - Optionally, backups/restores may be performed to handle failures
- combatentropy 8y agoI just make files of pure SQL to define the functions, keeping them in Git. I feed them into the psql command-line tool.
- zzzzzzzza 8y agoisn't this what sqitch does, manages deploying the changes to the db? Anyone have experience with sqitch?