Sql NHibernate和数据库更改/部署

我正在考虑在我的下一个项目中使用NHibernate和Fluent NHibernate，但有一件事我想先弄清楚，那就是如何管理对数据库的更改

例如，我让NH+FNH工作，应用程序已部署且处于活动状态，但我们在开发环境中进行了更改，例如，我们向使用NH/FNH映射的实体添加了一个新属性

如何将更改应用到数据库而不必删除表

多谢各位

---

好的，你需要手动操作。您可以在每次初始化中导出模式，但不能自动更改表。因为架构将只包含create语句

也许，您可以使用诸如Red Gate之类的工具来查找数据库差异，并自动创建语句。这个想法是,

-在测试数据库上生成架构
-运行红门工具，并在架构级别上查找差异。
-自动创建差异脚本

---

-在主数据库上应用差异无论您使用的是什么ORM工具，如果您进行模式更改，您将不得不同时部署代码和模式更改。对于我们的项目，这意味着对于包含模式更改的每个版本，我们都编写一个用于更新数据库的sql脚本。我们的安装程序在将包含新hibernate映射的代码部署到服务器的同时运行该脚本，并且在模式修改完成之前，新应用程序不会启动

---

使用这种技术，我们能够更改表、删除表、添加表以及将数据从一个表迁移到另一个表，而不会出现任何重大问题。通过脚本执行数据库修改，您可以在部署到生产环境之前对其进行全面测试。

我在使用此框架方面有很好的经验：

基本上，您为每个数据库更改创建一个类，并使用时间戳对该类进行注释。然后按时间戳顺序应用最终装配

这意味着在开发过程中，在每次签出之后，盲目地运行db升级过程变得很容易，并且知道您与世界同步

using Migrator.Framework;
using System.Data;

namespace DBMigration
{
    [Migration(20080401110402)]
    public class CreateUserTable_001 : Migration
    {
            public void Up()
            {
                    Database.CreateTable("User",
                            new Column("UserId", DbType.Int32,
                            ColumnProperties.PrimaryKeyWithIdentity),
                            new Column("Username", DbType.AnsiString, 25)
                            );
            }

            public void Down()
            {
                    Database.RemoveTable("User");
            }
    }

---

这就是我制定的流程。我认为它相当圆滑

假设您有一个名为“MyDb”的数据库，那么这个过程是这样的

在模型和映射中进行更改

运行一个脚本删除并重新创建一个名为MyDb_Next的数据库，然后执行NH SchemaExport将新的模式写入其中

接下来使用我的工具比较MyDb和MyDb_。这将通过比较模式和创建语句以添加新列等方式生成更改脚本（或尽可能多的更改脚本）。脚本将保存到VS项目中的xxxx-updatescript.sql.suggestive文件中

如有必要，修复建议的sql脚本（当它检测到可能丢失数据的更改时需要人工输入），并重命名为.sql（以便在下一步中提取）

包含sql脚本的项目上的生成后事件运行我的工具这将sql脚本应用于MyDb，使其更新

只要在更改实体时重复此过程即可。我通常将SQL脚本存储在.csproj中，并有一个运行simplescriptrunner的生成后事件。这样，执行更新和重建的任何其他开发人员都将在其计算机上使用签入编号的脚本生成最新版本的db

MigrationScriptGenerator使用OpenDBDiff（类似于Red Gate SQL Compare的开源工具）生成脚本。如果您想自己创建脚本，您可能会发现这很有用

---

PS这些工具仅适用于SQL Server-抱歉

NHibernate支持SchemaUpdate类，该类可以进行一些模式修改，但不是全部修改。更多详情如下：

---

我知道这是一个老问题，但我在谷歌遇到了这个问题，它是一个顶级结果，而且它没有提到NHibernate迁移的标准工具-

我意识到在许多商店中这是现实世界，这种做法可能会失控，特别是在需要高正常运行时间的任务关键型应用程序中。将代码更改部署到一组服务器（比如20+服务器）并同时更改数据库可能对正常运行时间非常有害，如果需要回滚，可能会导致长时间停机。所有这些都是好的方面。当我们发布一个版本时，我们确实会有一些停机时间，并且在几个小时后完成。我们有2台web服务器和1台数据库服务器。我很想看看你对你提到的问题的解决方案。很好。这基本上是rails方法的一个端口。FluentMigrator已经超过了migratordotnet，并提供了一种更易于管理（阅读：更少的手动脚本）的版本控制方法。