資料遷移系統的比選
資料模型在開發過程中往往會發生變化，到了某個時候就不再對應資料庫了。 當然，可以刪除資料庫，然後ORM將創建一個與模型匹配的新版本，但這個過程會導致現有資料的遺失。 因此，遷移系統的功能是確保在模式變更時與應用程式中的資料模型同步，而不會遺失現有資料。
在本文中，我們將了解用於管理資料庫遷移的各種工具。 我們希望這篇評論對面臨類似選擇的開發人員有用。
任務
我們公司目前正在積極開發下一代產品—Docs Security Suite (DSS)。 伺服器部分採用.Net Core編寫，並使用Entity Framework Core作為DBMS。 在設計應用程式時，我們使用“程式碼優先”方法。
應用程式域模型由多個開發人員同時創建 - 每個開發人員負責自己的系統邏輯部分。
上一代DSS使用經典的Entity Framework Migrations（EF 6）作為遷移管理系統。 然而，針對它的一些抱怨已經累積起來，主要的抱怨是 EF 缺乏解決版本衝突的明智方法。 在修復錯誤作為支持的一部分時，這一事實仍然讓我們感到不安，因此我們決定考慮其他選擇。
經過討論，形成了遷移管理系統的以下需求：
- 支援各種 DBMS。 需要 MS SQL Server、PostgreSQL、Oracle，但也可以使用其他
- 使用 ORM。 最初計劃使用 EF Core，但在設計階段我們準備考慮其他 ORM
- 自動產生遷移。 考慮到Code First的開發，我希望避免需要「手寫」遷移
- 版本衝突。 在分散式開發環境中，合併時，EF Core 可能會出現衝突。 這成為一個嚴重的問題，因為應用程式的不同部分是由不同的開發人員創建的，因此您必須在每個部分上花費大量時間
- 高級文件和支援。 在我們看來，這裡不需要解釋
- 自由的。 這個標準是有條件的，因為系統不是很昂貴或昂貴，但在便利性方面是理想的，我們也準備考慮
經過一些研究，發現以下選項值得考慮：
- EF Core 遷移
- 資料庫備份
- 圓屋E
- ThinkingHome.Migrator
- 流暢的遷移器
現在有更多細節
自然，這是第一個也是主要的選擇。 一種原生樂器，開箱即用，無需擺弄手鼓。 大量的文件、官方的與非官方的、簡單性等等。 然而，對經典 EF 的抱怨也與 EF Core 有關。
因此，EF Core 的優勢就凸顯出來了：
- Microsoft 支援、文件（包括俄語）、龐大的社區
- 基於CodeFirst自動產生遷移
- 與 EF 6 相比，EF Core 不再儲存資料庫的快照。 在 Code First 中使用 EF Core 時，不再需要部署資料庫
- 由於我們從 Code First 開始，因此可以對所有必需的資料存取提供者進行一次遷移
- 關於提供者，支援 PostgreSQL、支援 Oracle 等等，甚至還支援 MS SQL Server
還有缺點：
- 衝突解決保持在同一水平。 有必要對遷移進行排序並更新資料庫快照
- 對生成遷移的模型的依賴性
資料庫
DbUp 是一個由 NuGet 安裝的 .NET 函式庫，有助於將變更推送到 SQL Server。 它會追蹤已執行的更改腳本並運行更新資料庫所需的腳本。 函式庫源自 ASP.NET 上的一個開源部落格引擎項目，並在 MIT 許可下存在，程式碼位於 GitHub 上。 使用 T-SQL 描述遷移。
有什麼優點：
- 支援大量 DBMS（MS SQL Server、PstgreSQL、MySQL）
- 由於腳本是用 T-SQL 編寫的，因此看起來非常簡單
- 衝突也可以使用 SQL 解決
以及缺點：
- 支援的 DBMS 多種多樣，但 Oracle 並不是其中之一
- 不與 ORM 交互
- 手動編寫 T-SQL 腳本並不是我們的目標
- 文件和社群馬馬虎虎，儘管就編寫 SQL 腳本而言它們可能不是必需的。
圓屋E
與前一個遷移管理工具一樣，該遷移管理工具在 Apache 2.0 授權下分發，在 T-SQL 遷移引擎上運作。 顯然，開發人員優先考慮解決有關 DBMS 支援的技術問題，而不是創建舒適的開發流程。
優點：
- 支援必要的DBMS（包括Oracle）
缺點：
- .NET Core 不支援 Oracle（以及 Access，這與我們無關），僅支援 .NET Full Framework
- 不適用於 ORM
- 文件比以前的工具還要少
- 再次強調－遷移是由腳本編寫的
ThinkingHome.Migrator
用於將版本化資料庫架構遷移到 .NET Core 平台的工具，根據 MIT 授權分發。 .
優點：
- 專為 .NET Core 設計
- 實作了遷移的分支序列
- 實施遷移日誌記錄
缺點：
- 上次更新是在一年前。 顯然該項目不受支持
- 不受 Oracle 支援（文章指出這是由於 .NET Core 缺乏穩定的實現 - 但這是一年前的事了）
- 沒有自動產生遷移
總體而言，該項目看起來很有前途，特別是如果它要開發的話，但我們現在需要做出決定。
流暢的遷移器
最受歡迎的遷移工具，擁有大量粉絲。 根據 Apache 2.0 許可證分發。 如描述中所述，它是.NET 的遷移框架，類似於 Ruby on Rails 遷移。 對資料庫架構的變更在 C# 類別中描述。
這裡有以下優點：
- 支援所需的 DBMS
- .NET 核心支持
- 大型已開發社區
- 遷移之間的衝突依序解決－指定遷移的執行順序。 此外，如果一個實體出現衝突，則在合併程式碼時，將以與其餘程式碼相同的方式解決衝突
- 成功遷移後會執行一些設定檔。 而且可以承載服務功能，最後一次更新是一個月前，也就是專案存活了
至於缺點，它們是：
- 沒有自動產生遷移
- 與 EF 型號無連接
- 沒有資料庫快照
我們的選擇是什麼？
激烈的爭論圍繞著兩個參數——自動生成遷移和合理解決衝突。 其他因素就沒那麼可怕了。 結果，根據討論的結果，團隊決定在新專案中使用Fluent Migrator。 因為解決了未來的矛盾會帶來更多的好處。
發現
當然，沒有完美的工具。 所以我們必須優先考慮我們的「想要」才能做出選擇。 然而，對於其他團隊和其他任務來說，其他因素可能是決定性的。 我們希望這篇文章能幫助您做出選擇。
來源： www.habr.com