為關係數據庫建構分支版本控制模型
我是數據庫設計師，在我目前的項目中，我正在實現同時編輯 RDBMS 中的數據行所需的版本控制功能。項目要求說，數據編輯會話可以持續幾個小時或幾天，直到執行送出。此外，不同使用者同時修改同一數據時產生的衝突，應通過手動和半自動解決的可能性進行處理。換句話說，所需的編輯工作流程類似於在面向文件的版本控制系統中使用的工作流程，例如 SVN 或 Git。因此，傳統的 OLTP 方法和衝突解決策略（MVCC、樂觀/悲觀鎖）不能滿足我的限制。我對現有工具進行了一些觀察，這些工具為分支版本歷史和多版本工作流程提供了可能性：
- ArcSDE - ESRI 的 ArcGIS 支持通過 ArcSDE數據層對地理數據庫進行版本控制；
- Oracle Workspace Manager - Oracle 數據庫的特性，提供高度的版本隔離和數據歷史管理；
- SQL:2011 時間特性，包括有效時間和事務時間支持。
SQL:2011 並沒有解決我的問題，因為它提供了對“線性”編輯歷史的支持，而不是我正在尋找的分支。ESRI 和 Oracle 的解決方案是很好的候選方案，但我很失望它們都有供應商特定的介面來操作版本。似乎目前沒有人可以為關係數據的分支版本控制提供行業標準的解決方案（就像 SQL:2011 對臨時表和線性版本歷史所做的那樣）。作為一個新來的數據庫研究人員，我想了解：
- 關係數據庫社區是否對開發分支數據版本控制的標準模型感興趣，並且該領域的任何貢獻或研究是否有價值？（例如，以語言改進的形式對 SQL2011 中的時間特徵進行標準化）
- 開發人員和數據庫設計人員是否缺乏獨立於數據庫的開源中間件（類似於 ArcSDE），它提供對關係數據的分支版本管理的支持，或者在 RDBMS 本身中引入這些功能會更好？
我想我可以嘗試更深入地探勘並提出一些標準模型或子語言來處理類似 Git 的版本控制，但我不知道從哪裡開始。
IMO 這個問題缺乏足夠的普遍性來建立標准或可重用的解決方案。這真的只是一個你用數據建模解決的問題，
類似於以下內容：
CREATE TABLE DOC ( DOC_ID INT PRIMARY KEY, CURRENT_VERSION_ID INT, MODIFIED_AT DATETIME, MODIFIED_BY INT, CONSTRAINT FK_CURRENT_VERSION FOREIGN KEY (DOC_ID, CURRENT_VERSION) REFERENCES DOC_VERSION(DOC_ID,VERSION_ID) ) CREATE TABLE DOC_VERSION ( DOC_ID INT REFERENCES DOC, VERSION_ID INT, VERSION_OWNER INT, SOURCE_VERSION_ID INT, DOC_CONTENT NVARCHAR(MAX), CONSTRAINT PK_DOC_VERSION PRIMARY KEY (DOC_ID,VERSION_ID) )如果被版本化的內容不是作為 blob 儲存，而是在單獨的表中，則該模式仍然成立。所有儲存版本化數據的表都需要 VERSION_ID。
這肯定是一個有趣的研究項目，可以探索所有不同的方法，並討論解決衝突的選項，合併更改並勾勒出一般解決方案的樣子。
使用帶有觸發器的審計表可以很容易地管理和跟踪數據修改（插入、更新、刪除），該觸發器可以跟踪每個更改。
在管理 DDL（結構更改或過程程式碼更改）或 DCL（對象授權）時，需要進行版本控制。
市場上有一些數據庫強制變更管理解決方案，可以讓您對數據庫對象進行版本控制。
如果我將 RDBMS 比作文件系統，那麼它將是儲存在共享驅動器中的一個目錄，所有開發人員都可以同時對其進行修改。分支數據庫與 Git/SVN 中的分支過程相同——創建一個新目錄，相當於創建一個新的模式/數據庫。此外，還有需要覆蓋的共享情況，並製定強制更改策略以防止程式碼被覆蓋。
更多資訊歡迎閱讀《數據庫版本控制權威指南》白皮書