迁移器说明（FluentMigrator）？

有人可以解释迁移者（特别是流利者）的概念吗？

以下是我在这个主题上收集到的（可能是混乱的）事实：

• 它是一种通过版本控制最初创建然后维护数据库更新的方法。

• 第一个迁移（或数据库的初始版本）将包含所需的所有表，关系和属性（流畅地完成或在脚本中使用一大块sql）。

• 如果要将更改推送到数据库，可以创建新的迁移方法（向上和向下），例如添加新表或修改字段。

• 要部署其中一个迁移，您可以使用命令行指定包含迁移的dll，连接字符串和所需的版本。

如果您有一组相当复杂的数据模型，那么为所有这些模型创建迁移定义会不会非常困难和耗时？

我知道使用nHibernate / fluent，您可以轻松地为数据库生成表，而无需定义除模型和映射文件之外的任何内容。 有没有办法使此配置与Migrator / Versioning兼容？

当nhibernate / fluent负责生成数据库时，我不一定需要定义表的每个方面。 它通过约定或映射文件完成。 有了迁移器，我需要定义这个级别的细节吗？

Answer 1

这里有很多问题。 我将以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，连接字符串和所需的版本。

有三个可用于执行迁移的运行程序。 命令行运行器，Nant任务和MSBuild任务。 通常作为构建脚本的一部分执行。

MigrationRunner类也可以在代码中使用。 如果您想构建自己的跑步者或者您有其他需求（例如，如果添加了新的迁移，则动态构建数据库或自动更新数据库），您可以这样做。）

如果您有一组相当复杂的数据模型，那么为所有这些模型创建迁移定义会不会非常困难和耗时？

我已经回答了这个问题。 通常很容易为数据库生成sql脚本。 对于Sql Server，即使对于大型数据库，也只需不到一分钟即可生成脚本。 此脚本可以保存在.sql文件中，并使用Execute.EmbeddedSqlScript表达式作为第一次迁移执行。 它是一种享受。

我知道使用nHibernate / fluent，您可以轻松地为数据库生成表，而无需定义除模型和映射文件之外的任何内容。 有没有办法使此配置与Migrator / Versioning兼容？

目前，没有这样的整合，在实践中，我至少不要错过它。 有一些关于连接Fluent NHibernate和FluentMigrator的讨论，但这将是很多工作。 它将使脚手架能够像EF Code First迁移那样生成对模型的更改。 然而，目前不在路线图上。

当nhibernate / fluent负责生成数据库时，我不一定需要定义表的每个方面。 它通过约定或映射文件完成。 有了迁移器，我需要定义这个级别的细节吗？

是的，您需要在该级别详细定义。 FluentMigrators的迁移是一种DSL（自己的小语言），用于定义转换为sql的模式更改。 您也可以使用Execute.Sql表达式直接编写sql。 entity framework迁移具有这种集成，它既有优点也有缺点。

查看wiki或其中一个教程， 这里 （第1部分）或此处 （第2部分）有关入门的更多帮助。