我想將SQL Server數據庫的架構和“靜態”數據作為代碼保留在版本控制系統中。我還希望能夠將數據庫代碼的特定版本部署到相關數據庫的實際實例中，即將數據庫遷移到新版本（以及可選地“向下遷移”到舊版本）。

澄清

數據庫

我假設我不需要解釋什麼是數據庫或 SQL Server是一個特定的數據庫系統，即用於管理數據庫的特定軟件。

作為代碼的數據庫架構

在與數據庫一起工作的軟件開發人員中，希望能夠以“ 代碼”的形式維護數據庫的“ 模式”（即有關其結構的信息）。該代碼應允許某人創建具有與代碼表示相同的“模式”的數據庫。該代碼可以採用DDL（數據定義語言）語句的形式，例如 SQL代碼，通常是其特定於供應商的版本，用於在數據庫中創建諸如表和索引之類的對象，或者使用通用的編程語言，例如 Java， Ruby， C＃等。

版本控制和代碼

一旦架構數據庫的代碼以代碼表示，該代碼可以在版本控制或源代碼控制系統（用於管理版本控制的軟件）中維護。摘自Wikipedia：

修訂控制，也稱為版本控制和源代碼控制（以及軟件配置管理的一個方面），是對文檔，計算機程序，大型網站和其他信息收集。

維護表示版本控制系統中數據庫模式的代碼是可取的，因為可以保留模式更改的歷史記錄，並且可以訪問其他工具（例如我在此問題中詢問的工具集）

軟件部署

'部署'，在軟件開發的上下文中和軟件維護，涉及“ ...使軟件系統可用的所有活動。”。在這個問題的背景下，我對有關軟件工具的建議感興趣，這些軟件工具以SQL Server DBMS中具體的數據庫特定實例的形式提供特定版本的數據庫架構。

Example

作為示例，請考慮具有版本 v1 ， v2 和 v3 的數據庫架構，以及一些實際的數據庫，所有這些都具有那些模式的版本之一。對於此問題，推薦的軟件應具有將特定數據庫從其當前版本升級（或降級）到同一架構的任何其他版本的能力，並且應使用存儲在版本控制系統中的特定架構版本的代碼。

註釋中提到的某些特定條件

“選擇包含模式的版本控制項，（重新）對數據庫進行匹配（這到底意味著什麼？”

數據庫模式在版本控制系統中以代碼表示。我對直接與版本控制一起使用的工具不感興趣。這個問題所徵求建議的工具應該能夠利用數據庫模式的“版本”，模式“版本”的示例是表示特定版本（在Git中為“ commit”）或用於版本控制的特定標記/標籤的模式的代碼支持這些功能的系統。

以下是應為“（對）[目標]數據庫進行分級”以使其匹配的工具應提供的功能的基本列表：

表

• 如果源模式中存在表，但目標數據庫中不存在表，則該工具應在目標數據庫中創建表。這應該包括輔助對象，如鍵，約束，默認值，索引，觸發器等。
• 如果表在源模式中不存在 但存在 在目標數據庫中，該工具應提供用於指定是否應刪除目標數據庫中的表的方法。 [此設置可能適用於所有此類表。]

表列

• 如果源模式中的表中存在某個列，但目標數據庫中的same ^{1 sup>表，應在目標數據庫中創建它。作為大多數（？）DBMS的DDL語句，已經提供了為現有表指定新列的初始值的方式（例如，特別是對於不允許 NULL 值的新列） ），我不確定該工具本身是否需要提供任何特殊的東西來處理此問題。 但是，如果推薦的工具使用某種形式的“模式代碼”，而不是各個DBMS 2 sup>的標準DDL語句，則該工具應提供一些方法來指定}
• 如果表列在源模式中不存在 但在目標數據庫中存在 ，則工具應提供用於指定是否應刪除目標數據庫中的列的方法。 [此設置可能適用於所有此類表格列。]
• 如果源模式和目標數據庫中都存在相同的 ^{1 sup>表列，但是它們的類型不同或存在其他差異（例如長度，數字刻度等），則工具應更改目標數據庫中的列以匹配源模式，並儘最大努力保留該列中的現有數據。如果推薦的工具無法無損地轉換現有數據（例如，如果減少了列的長度並且需要將數據截斷的話），則退出報告失敗是非常有效的。}

表的輔助對象

這些對象的一些示例包括主鍵，外鍵約束，默認值和索引。

• 如果輔助對像是表源模式中存在某些表，但目標數據庫中不存在該表，因此應在目標數據庫中創建該表。如上所述，對於創建新表列，該工具應能夠處理涉及可能的衝突或添加輔助對象的錯誤的方案。對於該工具而言，只需將其交給維護架構代碼的人員以確保正確處理任何衝突或錯誤，就完全可以了-如果該工具遇到這樣的衝突或錯誤，退出報告失敗是完全有效的。 / li>
• 如果某個表附屬的對像在源模式中不存在 但在目標數據庫中存在 ，則該工具應提供用於指定是否輔助對象應放在目標數據庫中。 [此設置可能適用於所有此類對象。]
• 如果源模式和目標數據庫中都存在相同的 ^{1 sup>對象，則該工具應進行更改（或刪除和重新創建）目標數據庫中的對像以匹配源模式。}

其他對象

“其他對象”指的是視圖，存儲過程，用戶定義的函數等對象。通常可以安全地刪除這些對象並重新創建它們。對於依賴其他此類對象的對象（例如，引用另一個視圖的視圖），推薦的工具應該能夠按照必要的順序刪除並重新創建這些對象。

• 如果是其他對象，等，但存在於源模式中，但不存在於目標數據庫中，則應在目標數據庫中創建它。
• 如果諸如視圖之類的其他對像等等，不是存在於源模式中，但確實存在在目標數據庫中，該工具應提供一些方法來指定是否應刪除目標數據庫中的另一個對象。 [此設置可能適用於所有其他此類對象。]
• 如果源模式和目標數據庫中都存在這些對象之一，則該工具應更改（或刪除並重新創建）對象。目標數據庫以匹配源架構。

靜態數據

表中包含要同步的“靜態”數據的行應通過“該表的主鍵。

應該修改目標數據庫中靜態數據表中的行以匹配源模式。源模式中不在目標表中的行應插入目標表中。如果該工具提供了一種方法，該方法可以指定是否刪除源表中不存在 的目標表中存在的行，那就很好了。

說明

^{1 sup>這實際上是一個潛在的微妙之處！大多數工具可能會將具有相同名稱的數據庫對象實現為“相同”。但是至少在某些DBMS中有其他選擇，例如在SQL Server中，擴展屬性可用於為數據庫對象實現一種與對象名稱無關的持久性身份形式。這將很方便，因為該工具將能夠自動（至少在某些情況下）處理對象重命名的情況。}

^{2 sup>我具體詢問了SQL Server，但是在此如果任何人都可以 為所有DBMS提供該問題的答案，我真的很喜歡。}