Firstly, great article. Thanks for sharing. The migrations technique you outline is commonly used with ORM packages and assume that the database is tightly coupled to your application object model and all changes the database are tied to your application.
The problem with this pattern (and all source code control for RDBMS) is that you are not storing the database object but instead a text representation of the object as either a CREATE object or ALTER object script.
The functionality of migration scripts breaks down if your database has external dependencies such as linked servers as it is highly likely that your end point is completely different in Dev, QA and prod. Also branching and merging can be difficult and the migration pattern does needs care if you can also consider the table data as part of the database seeding. Eg. You introduce a config table that needs some base settings for environmental control (BG colour, company logo location, user account credentials for S3 file storage etc)
This is not to say it is not a valuable tool, just that it doesn't solve all problems
Alternatively look at Redgate toolbelt if you are on MSSQL. I suspect similar tools exist for other commercial RDBMS
Yes, the approach I show is more for projects in early stages. And as you mentioned branching and merging can be difficult, I've run into those problems before, didn't recall that to mention it, thank you for sharing your experience with this, I'll take a look to Redgate
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Firstly, great article. Thanks for sharing. The migrations technique you outline is commonly used with ORM packages and assume that the database is tightly coupled to your application object model and all changes the database are tied to your application.
The problem with this pattern (and all source code control for RDBMS) is that you are not storing the database object but instead a text representation of the object as either a CREATE object or ALTER object script.
The functionality of migration scripts breaks down if your database has external dependencies such as linked servers as it is highly likely that your end point is completely different in Dev, QA and prod. Also branching and merging can be difficult and the migration pattern does needs care if you can also consider the table data as part of the database seeding. Eg. You introduce a config table that needs some base settings for environmental control (BG colour, company logo location, user account credentials for S3 file storage etc)
This is not to say it is not a valuable tool, just that it doesn't solve all problems
Alternatively look at Redgate toolbelt if you are on MSSQL. I suspect similar tools exist for other commercial RDBMS
Yes, the approach I show is more for projects in early stages. And as you mentioned branching and merging can be difficult, I've run into those problems before, didn't recall that to mention it, thank you for sharing your experience with this, I'll take a look to Redgate