版本控制：此技術是否用於 DBMS 而非空間？
ESRI 的空間數據庫管理系統，稱為地理數據庫（更多），使用一種稱為版本控制的技術。
版本代表整個地理數據庫的時間快照，並包含地理數據庫中的所有數據集。
版本不是地理數據庫的單獨副本。相反，版本和其中發生的事務在系統表中進行跟踪。這將使用者的工作隔離在多個編輯會話中，允許使用者在不鎖定生產版本中的功能或立即影響其他使用者且無需製作數據副本的情況下進行編輯。
http://help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/concepts/versioning/basicprinciples/state.htm
當您將數據集（要素類、要素數據集或表）註冊為版本時，會創建兩個增量表：A（或添加）表，用於記錄插入和更新，以及 D（或刪除）表，用於儲存刪除。每次更新或刪除數據集中的記錄時，都會將行添加到這些表中的一個或兩個中。因此，版本化數據集由原始表（稱為基本表或業務表）加上增量表中的任何更改組成。當您進行填充增量表的編輯時，地理數據庫會跟踪您連接到的版本。當您在某個版本中查詢或顯示數據集時，ArcGIS 會組合原始表和增量表中的相關行，以呈現該版本數據的無縫視圖。
老實說，我發現文件相當模糊。它並沒有告訴我太多關於該技術實際上是如何工作的，或者它基於傳統數據庫理論的哪一部分。
我不認為許多 DBA SE 社區成員會有使用 ESRI 版本控制技術的經驗。所以我不會問諸如“它是如何工作的？”之類的問題。
相反，我想知道，在非空間數據庫世界中是否有任何類似於 ESRI 版本控制的技術？
Oracle 幾乎從一開始就實施了 MMVC。它的主要目的是減少更新期間的爭用：使讀者和作者不會相互阻塞。但這與 ESRI 提供的多版本控制不同。傳統的數據庫事務是短事務：它們只持續很短的時間：亞秒、秒……對於某些批處理可能是幾分鐘甚至幾小時。
ESRI 提供的版本控制是針對長事務的。在這裡，一個事務可以持續數天、數週、數月……理論上，數據庫可以使用短事務來做到這一點：只是不要送出，並希望您的會話持續數天或數月。顯然是不可能的保證。
所以甲骨文實現了自己的長事務/多版本機制。它被稱為 Oracle Workspace Manager (OWM)。有關詳細資訊，請參閱http://docs.oracle.com/database/122/ADWSM/。
在 OWM 中，使用者在工作空間中工作（ESRI 稱之為版本）。工作空間是協作的：多個使用者可以在同一個工作空間中工作。在工作區中完成的更新僅對該工作區中的使用者可見。工作空間中的更改通過合併操作應用到父工作空間。子工作區可以通過刷新操作開始查看在其父工作區中所做的更改。OWM 包括用於衝突檢測和解決、長期鎖定、變更檢測、歷史記錄、“假設”場景的所有機制……
與 ESRI 的版本一樣，OWM 的工作空間形成了嵌套工作空間的層次結構，最上面的一個是 LIVE（或“已建構”工作空間）。
OWM 對應用程序是完全透明的：它們像往常一樣與表和視圖互動。在每個工作空間的上下文中維護參照完整性。
請注意，OWM 與 GIS 沒有特別相關：多版本表可以是任何類型的 - 不僅僅是“空間”表。但是，許多需要安全長事務機制的 GIS 工具都使用它：Autodesk Map、Bentley Maps、Geomedia Transaction Manager 就是範例。許多客戶也在任何 GIS 之外使用它。
從概念上講，它與 ESRI 的方法非常相似：基本操作相同（但可能使用不同的術語）。然而，實現是不同的：ESRI 將更改保存在單獨的表（“A”和“D”表）中，而 Oracle Workspace Manager 將它們全部保存在主表中。視圖使使用變得透明。
所以是的，在空間數據庫的其他上下文中，多版本/長事務肯定在數據庫中使用。