4 ms·
As someone who built (and sold) a company in this space, your solution works for the vast majority of relatively simple databases. However, lots of legacy/ente
by mattzito 6y ago
As someone who built (and sold) a company in this space, your solution works for the vast majority of relatively simple databases. However, lots of legacy/enterprise/custom apps have freakishly complicated schemas running on databases that have been so over-engineered as to create problems for themselves (cough Oracle *cough).
In practice, you end up having lots of complex restrictions - you have to change your schema definition slightly between dev and prod, because your dev box is linux and your prod machine is AIX and there's a bug in your dbms on AIX. You can't just drop stored procedures, because rebuilding them takes 30 minutes of downtime you can't allow for. Or you have security policies on data in prod that changes the table definition.
In an ideal world you wouldn't need these things, but once you have a complicated enough system, you basically have to have a tool that does your database release management.