数据库迁移：使用构建脚本进行管理还是在应用程序启动时自动进行？
我正在为新的 Web 应用程序开发部署系统，我想知道管理数据库迁移的过程中的最佳点在哪里（如何进行迁移的问题完全是另一个问题）。
似乎有两种方法可以选择：
- 使用可以的迁移脚本 可以通过命令手动运行 线或作为自动的一部分 部署/构建过程
- 当应用程序运行时运行迁移 启动（我正在使用 ASP.NET 所以这 可以很容易地完成，无需 导致长时间运行的用户请求）
有人对这些方法有任何建议/见解/经验吗？ 还有其他建议吗？
我明白为什么#1 可能更有吸引力 - 它让我可以完全控制数据库的更新时间。 然而，我非常喜欢#2，因为它允许我在部署之间快速迭代并减少手动过程。 #2 也可以用在我的开发机器上，以实现更快的迭代。 嗯，开始认为拥有两者可能是一件好事......
I'm in the process of developing a deployment system for a new web app and I'm wondering where the best point in the process to manage database migrations is (the question of how to do the migrations is another problem entirely).
It seems there are two ways to go:
- Use a migration script that can
either be run manually from command
line or as part of the automatic
deployment/build process - Run the migrations when the app
starts up (I'm using ASP.NET so this
can be done easily enough without
causing a long-running user request)
Does anyone have any suggestions/insight/experience with these approaches? Any other suggestions?
I can see why #1 might be more attractive - it gives me complete control over when the DB is updated. However, I quite like #2 as it allows me to quickly iterate between deployments and reduces the manual process. #2 could also be used on my development machine to allow even quicker iterations. Hmm, starting to think having both might be a good thing...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们有一个拥有约 100 个客户端的销售人员系统，并且我们在应用程序启动时更新数据库（确实，我们是一个桌面应用程序。）我喜欢这种方法，如果我们有不确定的起点（客户端数据库是新的还是新的），它是安全且可迭代的。只更新到版本xyz？）。
但在服务器端，我更喜欢第 1 个选项：我们在虚拟机上创建一个 SQL 查询文件（基于原始数据库的副本），并针对真实服务器运行此查询。
所以恕我直言：
所以我也对这个问题感兴趣，并找到了一些（一半）框架为 RikMigrations。 经过一番谷歌搜索后，有一个关于数据库版本控制/迁移框架的良好起点： .NET数据库迁移工具综述。 不一定是文档，但团队博客可能很有趣。
We have a sales-force system with ~100 client and we are updating database at application startup (True, our is a desktop application.) I like this approach, it's safe and iterative if we have indeterministic startpoint (is the client database new or only updated to verison x.y.z?).
But at serverside I'm preferr your #1 option: we create a SQL query file on our virtual machine (based on the copy of the original database) and runs this query against the real server.
So IMHO:
So I'm interrested in this problem too, and find some (half)frameworks as RikMigrations. After some googling there is a good startplace about DB versioning/migration frameworks: .NET Database Migration Tool Roundup. Not neccessarely the documentation but the team blogs can be interresting.
我更喜欢选项#1，因为它看起来更灵活。 我想我应该验证数据库架构（版本号？）是否与代码匹配，而不是在每个应用程序启动时实际执行迁移，如果不匹配，则抛出有关不匹配的数据库架构的警告或错误。
I like option #1 better as it seems much more flexible. In lieu of actually performing migrations on each app start, I think I would verify that the database schema (version number?) matches the code, and if not, throw a warning or error about a mismatched database schema.
出于多种原因，我更喜欢选项#1。 首先，集成测试通常要求您的数据库架构是最新的，而启动网站来升级架构将是一个巨大的时间浪费。 其次，您无法在站点运行时更改数据库架构（例如，添加几个索引以加快速度）。
至于生产方面，在事务 MSI 样式安装中升级数据库比尝试在每个应用程序启动时升级要好得多，因为您可能最终会得到不同步的数据库应用程序版本。
如果您正在寻找迁移框架，请查看 Wizardby。
I'd prefer option #1 for a number of reasons. First, integration tests usually require your DB schema to be up-to-date, and launching a web-site to upgrade the schema will be a huge timewaster. Second, you cannot change database schema while your site is running (say, add a couple of indexes to speed things up).
As for production side of things, upgrading your database in transaction MSI-style installation is much better than attempting to upgrade at each app startup since you can potentially end up with desynchronized database-application versions.
And if you're looking for the migration framework, take a look at Wizardby.
如果应用程序必须在客户的计算机上运行，那么在启动时进行迁移可以避免大量的支持电话 - 假设您可以在没有用户干预的情况下进行无缝迁移（我希望您通常不会在具有修改数据库的权限的情况下运行您的 Web 应用程序） ）。
如果应用程序始终在您的控制下运行，那么自动迁移就不是什么问题了，但仍然是一个很好的功能，特别是如果您希望最大限度地减少停机时间和手动部署步骤。
If the application ever has to run on a customer's machine than migrating at startup can prevent a lot of support calls - assuming you can do seamless migration without user intervention (I hope you aren't normally running your web app with permission to modify the database).
If the application always runs under your control automatic migration is less of an issue - but still can be a good feature, especially if you want to minimize downtime and manual deployment steps.