进化数据库迁移和默认数据
我们正在重新评估应用程序的数据库升级过程，以尝试消除在发布周期结束时必须为某个版本生成所有升级脚本的痛苦。我们希望走向一个更加进化的过程，使用迁移与功能一起通过诸如 migratordotnet，这似乎是管理架构更改的一种非常干净的方式。
然而，我们的数据库附带的默认数据经常会发生变化，其中一些数据更新不太适合迁移过程。例如，对具有 Identity 主键的表的插入不易识别，因此在降级时无法逆转。
所以我想知道人们如何管理默认数据的迁移？他们是否在计划迁移过程之外对其进行管理？或者在迁移期间执行插入，但在降级期间不执行数据删除？
We're re-evaluating our database upgrade process for our application to try and remove the pain of having to generate all the upgrade scripts for a release at the end of the release cycle. We're looking to move towards a more evolutionary process, using migrations which are checked in alongside features with a tool such as migratordotnet, and this seems like a very clean way of managing schema changes.
However, the default data which is shipped with our database is quite regularly subject to change and some of these data updates do not fit well with the migration process. For example, inserts to tables which have an Identity primary key are not easily identifiable and so cannot be reversed on downgrading.
So I'm wondering how people manage the migration of default data? Do they managed it outside of the scheme migration process? Or are inserts performed during migrations but the removal of the data is not performed during downgrades?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于我们来说，数据库迁移是日常开发过程的一部分。开发人员必须提交执行必要更改的程序或脚本。一旦相关功能实现，就会发生这种情况，而不是“在发布周期结束时”。
降级很少会成为问题，但如果有的话，请创建一个包含版本信息的列。当升级成功并且客户决定保留新版本时，再次删除该列（或保留它）。
成功的关键是我们拥有大量的测试用例，这些测试用例从头开始创建数据库（使用 H2 等内存数据库或安装在每台开发人员计算机上的数据库），包括所有数据，然后将其全程迁移和返回。我们可以将生产服务器中的匿名数据导入到测试用例中，以跟踪错误并改进测试，而不会侵犯客户的隐私或妨碍开发人员。
For us, DB migration is part of the daily development process. Developers have to either commit a program or a script which performs the necessary changes. This happens as soon the related feature is implemented and never "at the end of the release cycle".
Downgrade is rarely an issue but if you have it, create a column with a version information. When the upgrade succeeds and the customer decides to stay with the new version, drop the column again (or keep it).
The key for success is that we have extensive test cases which create the database from scratch (using an In-Memory DB like H2 or a DB which is installed on each developer machine) including all data and then migrate it all the way through and back. We can import anonymized data from the productions servers into the test cases to track down bugs and improve tests without violating the privacy of our customers or getting in the way of the developers.