很多問題在這裏。我將回答這些問題,重點關注FluentMigrator。
這是一種通過版本控制的方式初始創建並維護數據庫的更新 。
FluentMigrator是一種版本控制數據庫架構的方法。每個人都以某種方式做它。手動,使用sql腳本,使用SqlCompare或Visual Studio數據庫項目等工具。所有這些方法都很容易搞砸。當發佈新版本並導致系統崩潰時,很容易出錯。遷移是處理此問題的更好方法。
FluentMigrator允許您定義更改架構的代碼,這通常是簽入到與其他代碼更改源代碼控制。這意味着你可以說系統的版本1.XX應該有數據庫的版本123。這意味着如果您將代碼回滾到以前的版本,您也會知道要回滾到哪個版本的數據庫。
它既可以用來從頭創建數據庫模式,也可以從現有數據庫的模式版本控制開始。
遷移是一種描述數據庫模式更改的方法。FluentMigrator創建一個VersionInfo表,並存儲遷移後的唯一標識(版本號)。
例如,如果我有兩個遷移一個與Id 1和一個與Id 2.如果然後我執行第一個遷移然後Id 1將存儲在VersionInfo表中,我可以看看那裏,知道版本該數據庫爲1,該版本2尚未應用。
能夠知道哪個版本的數據庫模式在推送從測試到生產的更改時非常有用,或者您在生產中有多個數據庫副本。例如,我有一個在世界各地都設有辦事處的客戶,每個辦事處都有自己的數據庫副本,而且他們都是不同的版本。在不知道數據庫版本的情況下,安全地更新它們將非常困難。
大多數情況下,我不需要真正查看VersionInfo表格,FluentMigrator會自動處理它。它將程序集與Migrations進行比較,並確定尚未應用哪些更改,然後執行這些更改。
第一遷移(或數據庫的初始版本)將包含所需 所有表,關係和屬性(在腳本做到無論 流利或使用SQL的塊)。
起點取決於您。您可以進行第一次遷移,該遷移是從當前數據庫中生成的sql腳本。您也可以使用其中一個像這樣的contrib項目來生成Fluent遷移。或者你可以決定現有的數據庫是一個起點,並保存它的一個副本,以便將其恢復爲版本1.
我已經將FluentMigrator引入了很多遺留數據庫,沒有出現任何重大問題。
當你想要把更改的數據庫,你會創建一個新的 遷移方法(上下),像添加新表或 修改字段。
是的,Up用於應用在Migration和Down中指定的更改將其返回。所以Up可以創建一個表格,Down可以放置表格。
要部署這些遷移的一個,將使用指定包含遷移,連接字符串和 所需版本的dll命令行 。
有三個runners可用於執行遷移。命令行運行程序,Nant任務和MSBuild任務。通常作爲構建腳本的一部分執行。
MigrationRunner類也可以在代碼中使用。你可以這樣做,如果你想建立自己的亞軍或者如果您有其他需求(如動態構建數據庫或自動如果添加了新的遷移更新數據庫。)
如果你有一個相當複雜的數據模型,這難道不是 困難且耗時的創建所有 的遷移定義嗎?
我已經主要回答了這個問題。爲數據庫生成一個sql腳本通常很容易。對於Sql Server,即使對於大型數據庫,也只需不到一分鐘即可生成腳本。該腳本可以保存在.sql文件中,並使用Execute.EmbeddedSqlScript表達式作爲第一次遷移來執行。它工作的一種享受。
我知道與NHibernate /流利,你可以很容易地生成一個 數據庫表,而不必定義比模型和 地圖文件的其他任何東西。有沒有辦法使此配置與遷移器/版本控制的 兼容?
目前沒有這樣的整合,實際上我至少不會錯過它。關於連接Fluent NHibernate和FluentMigrator有一些討論,但這將是很多工作。它可以使腳手架產生對EF Code First遷移所做的模型更改。然而,目前這還不是路線圖。
當nhibernate/fluent負責生成數據庫時,我不需要定義表的每個東西方面。它通過約定或通過映射文件完成 。與移民我 將需要定義此級別的細節?
是的,您需要定義該詳細程度。 FluentMigrators的遷移是一種DSL(自己的小語言),用於定義轉換爲sql的模式更改。你也可以使用Execute.Sql表達式直接編寫sql。實體框架遷移具有這種兼有優點和缺點的整合。
退房的wiki或教程之一here,here(第1部分)或更多的幫助here(部分2)開始。