有人可以解释迁移者（特别是 fluentmigrator）的概念吗？
以下是我收集到的关于这个主题的（可能令人困惑的）事实：
它是一种通过版本控制最初创建然后维护数据库更新的方法。
第一次迁移（或数据库的初始版本）将包含所需的所有表、关系和属性（流利地完成或使用脚本中的一段 sql 完成）。
当您想将更改推送到数据库时，您将创建一个新的迁移方法（向上和向下），例如添加新表或修改字段。
要部署这些迁移之一，您将使用命令行指定包含迁移、连接字符串和所需版本的 dll。
如果您有一组相当复杂的数据模型，那么为所有这些创建迁移定义会不会相当困难和耗时？
我知道使用 nHibernate/fluent 您可以轻松地为数据库生成表，而无需定义模型和映射文件以外的任何内容。有没有办法让这个配置与迁移器/版本兼容？
当 nhibernate/fluent 负责生成数据库时，我不一定需要定义表的所有方面。它通过约定或通过映射文件完成。对于迁移者，我需要定义这种详细程度吗？
这里有很多问题。我将重点回答有关 FluentMigrator 的问题。
它是一种通过版本控制最初创建然后维护数据库更新的方法。
FluentMigrator 是一种对数据库模式进行版本控制的方法。每个人都以某种方式做到这一点。手动，使用 sql 脚本，使用 SqlCompare 或 Visual Studio 数据库项目之类的工具。所有这些方法都很容易搞砸。发布新版本时很容易出错，导致系统崩溃。迁移是处理此问题的更好方法。
FluentMigrator 允许您将架构更改定义为代码，这通常与其他代码更改一起签入到您的源代码管理中。这意味着您可以说您的系统版本 1.XX 应该具有版本 123 的数据库。这意味着如果您将代码回滚到以前的版本，您也知道要回滚到哪个版本的数据库。
它既可用于从头创建数据库模式，也可用于对现有数据库的模式进行版本控制。
迁移是一种描述数据库架构更改的方法。FluentMigrator 创建一个 VersionInfo 表并存储应用后迁移的唯一 id（版本号）。
例如，如果我有两个迁移，一个 ID 为 1，一个迁移 ID 为 2。如果我执行第一个迁移，那么 ID 1 将存储在 VersionInfo 表中，我可以查看那里并知道数据库的版本是 1并且该版本 2 尚未应用。
在将更改从测试推送到生产或者如果您在生产中有多个数据库副本时，能够知道数据库架构的哪个版本非常有用。例如，我有一个客户在世界各地都有办事处，每个办事处都有自己的数据库副本，而且所有的数据库都在不同的版本上。如果不知道数据库版本，就很难安全地更新它们。
大多数时候我不需要真正查看 VersionInfo 表，FluentMigrator 会自动处理这个。它将带有迁移的程序集与 VersionInfo 表进行比较，并找出哪些更改尚未应用，然后执行这些更改。
第一次迁移（或数据库的初始版本）将包含所需的所有表、关系和属性（流利地完成或使用脚本中的一段 sql 完成）。
起点由您决定。您可以进行第一次迁移，它是您从当前数据库生成的 sql 脚本。您还可以使用FluentMigrator.T4等贡献项目之一来生成 Fluent Migration。或者您可以决定以现有数据库为起点并保存其副本以便能够将其恢复为版本 1。
我已经将 FluentMigrator 引入了许多遗留数据库，没有任何重大问题。
当您想将更改推送到数据库时，您将创建一个新的迁移方法（向上和向下），例如添加新表或修改字段。
是的，Up 用于应用 Migration 中指定的更改，Down 将其回滚。所以 Up 可能是创建一个表， Down 可能是删除表。
要部署这些迁移之一，您将使用命令行指定包含迁移、连接字符串和所需版本的 dll。
有三个运行程序可用于执行迁移。命令行运行程序、Nant 任务和 MSBuild 任务。通常作为构建脚本的一部分执行。
MigrationRunner 类也可以在代码中使用。如果您想构建自己的运行器或有其他需求（例如动态构建数据库或在添加新迁移时自动更新数据库），您可以这样做。
如果您有一组相当复杂的数据模型，那么为所有这些创建迁移定义会不会相当困难和耗时？
我已经回答了这个问题。为数据库生成 sql 脚本通常很容易。对于 Sql Server，即使对于大型数据库，也只需不到一分钟的时间即可生成脚本。此脚本可以保存在 .sql 文件中，并使用 Execute.EmbeddedSqlScript 表达式作为第一次迁移执行。这是一种享受。
我知道使用 nHibernate/fluent 您可以轻松地为数据库生成表，而无需定义模型和映射文件以外的任何内容。有没有办法让这个配置与迁移器/版本兼容？
目前，还没有这样的整合，至少在实践中我不会错过它。有一些关于连接 Fluent NHibernate 和 FluentMigrator 的讨论，但这将是很多工作。它将使脚手架能够像 EF Code First 迁移一样生成对模型的更改。然而，它目前不在路线图上。
当 nhibernate/fluent 负责生成数据库时，我不一定需要定义表的所有方面。它通过约定或通过映射文件完成。对于迁移者，我需要定义这种详细程度吗？
是的，您需要在该详细级别进行定义。FluentMigrators 的迁移是一种 DSL（自己的小语言），用于定义转换为 sql 的架构更改。您也可以使用 Execute.Sql 表达式直接编写 sql。实体框架迁移具有那种既有优点也有缺点的集成。