Reasons for not migrating using a single query
Evolution is a constant in the software industry. Most of the times migrations are done, the database and code changes are simultaneous and all of this is deployed in a big bang release. An example of a big bang release in our case would be to make the constraint, make data changes, and delete the relationships in one go. This change will need the code to be deployed along with the changes to the database so that the applications keep running. There are multiple downsides to this approach:
If something goes wrong at the database end, there might be an outage. A rollback of code will be required along with restoring the database to an earlier state.
This is more time consuming since it will require a lot more testing and preparation than smaller increments, which can be leak proofed.
If we separate the migration into two steps—constraint and path creation, and relationship removal—we gain the following advantages:
Since constraint and path creation...
