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