Is it a way to initially create then maintain updates for a database
by way of versioning.

FluentMigrator是一种版本控制数据库模式的方式.每个人都以某种方式做到这一点.手动使用sql脚本,使用sqlCompare或Visual Studio数据库项目等工具.所有这些方法都很容易搞砸.在发布新版本并导致系统崩溃时,很容易犯错误.迁移是更好的方式来处理这个问题.

FluentMigrator允许您将模式的更改定义为代码,通常会使用其他代码更改来检查源代码控制.意味着你可以说系统的版本1.XX应该有版本123的数据库.这意味着如果您将代码回滚到以前的版本,您还可以知道要回滚的数据库的哪个版本.

它可以用于从头开始创建数据库模式,也可以从现有数据库的模式的版本控制开始.

迁移是描述数据库模式变化的一种方式. FluentMigrator创建一个VersionInfo表,并存储适用于迁移的唯一ID(版本号).

例如,如果我有两个迁移,一个具有Id 1,一个具有Id 2.如果然后我执行第一个Migration,那么Id 1将被存储在VersionInfo表中,我可以看到那里,知道数据库的版本是1该版本2尚未应用.

能够知道哪个版本的数据库模式在从“测试”到“生产”推送更改时非常有用,或者在“生产”中有多个数据库副本.例如,我有一个在世界各地设有办事处的客户,每个办公室都有自己的数据库副本,所有这些都在不同的版本上.不知道数据库版本,将很难安全地更新它们.

大多数时候,我不需要实际查看VersionInfo表,FluentMigrator会自动处理.它将汇编与迁移比较到VersionInfo表,并确定哪些更改尚未应用,然后执行那些.

The first migration (or initial version of the database) would contain
all the tables,relationships and properties required (done either
fluently or using a chunk of sql in a script).

起点取决于你.您可以进行第一次迁移,这是从当前数据库生成的sql脚本.您还可以使用其中一个诸如FluentMigrator.T4的contrib项目来生成流畅的迁移.或者您可以仅仅决定现有的数据库是起始点,并保存其副本以便将其还原为版本1.

我已经将FluentMigrator引入了许多遗留数据库,没有任何重大问题.

When you want to push a change to a database,you would create a new
migration method (Up and Down),something like add a new table or
modify a field.

是的,Up用于应用在“迁移”和“Down”中指定的更改.所以可以创建一个表,而Down可以放下表.

To deploy one of these migrations,you would use a command line
specifying the dll containing the migration,the connection string and
the required version.

有三个runners可用于执行迁移.命令行跑步者,Nant任务和MSBuild任务.通常作为构建脚本的一部分执行.

MigrationRunner类也可以在代码中使用.如果您想要构建自己的运行程序或者有其他需求(例如,如果添加了新的迁移,动态构建数据库或自动更新数据库),则可以执行此操作.

If you had a rather complex set of data models,wouldn’t it be rather
difficult and time consuming to create a migration definition for all
of that?

我已经大部分回答了.为数据库生成一个sql脚本通常很容易.对于sql Server,即使对于大型数据库也可能需要不到一分钟的时间生成脚本.该脚本可以保存在.sql文件中,并使用Execute.EmbeddedsqlScript表达式作为第一次迁移执行.它可以治疗.

I know with nHibernate/fluent you can easily generate tables for a
database without having to define anything other than the models and
map files. Is there a way to make this configuration compatible with
the Migrator/Versioning?

目前,没有这样的一体化,实际上我至少不要错过.有一些关于连接Fluent NHibernate和FluentMigrator的讨论,但这将是很多工作.它将使脚手架能够生成模型的更改,如EF Code First迁移.目前还没有在路线图上.

When nhibernate/fluent is in charge of generating a database,I do not
necessarily need to define every thing aspect of the tables. Its done
either via convention or via the mapping files. With the migrators I
would need to define this level of detail?

是的,您需要在该级别的细节上进行定义. FluentMigrators的迁移是一种DSL(自己的小语言),用于定义转换为sql的模式更改.您也可以使用Execute.sql表达式直接编写sql.实体框架迁移具有这样的一体化,既有优缺点.

查看wiki或其中一个教程here,here(第1部分)或here(第2部分)了解更多帮助入门.