如何處理非SQL數據庫上的數據方案更改？

Question

正如我所瞭解的非SQL數據庫一樣，最大的問題之一是模式更改。在SQL數據庫上添加或刪除列操作非常簡單，服務器可以在方案更改期間保證數據的穩定因此它可以在服務推進期間處理數據模式更改。但是如何讓非SQL數據庫（尤其是客觀的樣式系統）處理這些模式更改？有沒有可靠的方法？

Answer 1

我同意Skaffman的看法，非SQL數據庫涵蓋了廣泛的產品。每個人都傾向於提供不同級別的模式管理。

例如，鍵/值對數據庫，如Oracle Berkeley DB是無模式的。放置在鍵/值對中的是一個不透明的結構，訪問它的應用程序已知它。在這種情況下，我經常看到應用程序在鍵/值對數據結構中實現了一個字段來指示模式版本。應用程序在讀取或寫入記錄時將根據找到的模式版本採取適當的操作。這對於某些應用程序可能是有利的，因爲可以根據給定的讀/寫操作而不是批量應用程序架構更改。

另一個例子，XML數據庫，如Oracle Berkeley DB XML以自描述的XML格式存儲數據。儘管集合中的大多數XML文檔具有相同的模式是很常見的，但模式對於給定文檔具有更多或更少的屬性當然是可能的，甚至是理想的。這些非SQL數據庫採用查詢語言（如XQuery），可以查詢數據的結構（屬性）以及內容。

在又一個示例中，基於對象的數據存儲（如Berkeley DB提供的Data Persistence Layer API）可以支持作爲基礎API的一部分的面向應用的模式演變，如here所述。

但是，即使使用SQL數據庫，也只能輕鬆更改表面上的模式。應用程序通常必須意識到任何模式更改才能正常運行。在SQL數據庫中添加列可能會對執行「SELECT *」的應用程序產生不利影響，而重命名或刪除列可能會對假定存在該列的應用程序產生負面影響。 SQL數據庫使模式更改變得「簡單」，因爲有一個SQL命令允許您添加，刪除和重命名列。架構上的架構管理需求仍然需要思考並正確實施。

底線，典型的模式演化是由數據庫引擎，應用程序或中介API層管理的。至於它如何「容易」，取決於它上面的應用程序層以及它們如何受模式更改的影響。

如果您可以更具體地瞭解您嘗試解決的問題，我們可能會提供更具體的建議。特別是，您正在使用哪個數據庫，以及您如何看待您的模式演變？

問候，

戴夫