3 ms·
If you have any suggestions for how to solve this problem in a different way I'd love to hear them. I'm struggling with it myself, so if there's an easier way o
by dbla 14y ago
If you have any suggestions for how to solve this problem in a different way I'd love to hear them. I'm struggling with it myself, so if there's an easier way of doing it I'm very interested.
- pnathan 14y agoHonestly, from your problem statement, I would presume that the solution is to use a single branch in your VCS for your deployment, with strict controls on branching and merging, ensuring that a consistent upgrade path is presented to the DBMS at all times. I would probably strive for a tool that would detect conflict and print a report, with the developers themselves managing the merging in the SCM. Although I'm not a DB specialist, I have a profound distrust of GUI tools for this sort of thing; they've died and the DB schema work I was doing was entirely borked. This has happened multiple times across multiple tools. I kind of develop an allergy to certain styles of work in consequence. :-) I know someone who does all his schema work in the DB itself; there's no SCM versioning of the DDL. I don't understand how that's responsible software engineering. No one else can examine the versions, diffs aren't available, there's no record of what it really is, as opposed to the live-coding. (I do a lot of work in Lisp - I learned real quick that you really want files & source control instead of letting things all hang out in the REPL waiting for you to crash it. The database isn't too different in spirit).