数据库迁移:使用生成脚本管理还是应用程序启动时自动管理?

我们有一个销售人员系统,大约有100个客户机,我们正在应用程序启动时更新数据库(没错,我们是桌面应用程序)。我喜欢这种方法,如果我们有不确定的startpoint(客户机数据库是新的还是只更新到verison x.y.z?),那么它是安全的、迭代的。.

但在服务器端,我更喜欢您的1选项:我们在虚拟机上创建一个SQL查询文件(基于原始数据库的副本),并在真实服务器上运行此查询。

所以IMHO:

• 断开连接的客户端: 启动,迭代脚本
• 服务器: 基于实际和真实数据库在虚拟机上创建的查询

所以我也被这个问题困扰了,找到了一些(一半)框架 RikMigrations . 在经过一些谷歌搜索之后,关于DB版本控制/迁移框架有了一个很好的起点: .NET Database Migration Tool Roundup . 不一定是文档,但是团队博客可能会有问题。

我更喜欢选项1,因为它看起来更灵活。代替在每个应用程序启动时实际执行迁移,我想我应该验证数据库模式(版本号?)与代码匹配,如果不匹配,则抛出有关不匹配的数据库架构的警告或错误。

我比较喜欢选项1,原因有很多。首先,集成测试通常要求您的db模式是最新的,而启动一个网站来升级该模式将是一个巨大的时间浪费。其次,在站点运行时不能更改数据库模式(例如,添加两个索引以加快速度)。

至于生产方面,在事务msi风格的安装中升级数据库要比在每次启动应用程序时尝试升级好得多,因为可能会导致数据库应用程序版本不同步。

如果您正在寻找迁移框架,请查看 Wizardby .

如果应用程序必须在客户的机器上运行,那么在启动时迁移可以阻止很多支持调用—假设您可以在没有用户干预的情况下进行无缝迁移(我希望您通常不会在有权限修改数据库的情况下运行Web应用程序)。

如果应用程序总是在您的控制下运行,那么自动迁移就不那么麻烦了,但仍然是一个很好的特性,特别是如果您希望最小化停机时间和手动部署步骤。