面向文檔的數據庫 - 如果文檔定義更改會怎樣？

Question

據我所知，您可以將任何非結構化信息輸入到面向文檔的數據庫中。讓我們想象一下這樣一個文件：

{ 
    name: 'John Blank', 
    yearOfBirth: 1960 
} 

後來，在新版本中，這個結構重構爲

{ 
    firstname: 'John', 
    lastname: 'Blank', 
    yearOfBirth: 1960 
} 

如何與文檔面向數據庫做到這一點？你是否必須準備合併腳本，這會改變數據庫中的所有條目？還是有更好的方法可以處理結構中的變化？

Answer 1

此處的重構意味着存在從舊模式到新模式的確定性映射。所以最有效的選擇是對SQL數據庫做同樣的事情並實際更新文檔。

面向文檔的數據庫給你做一個選擇，雖然這取決於其DODB以及如何你使用它的前端。該選項只是簡單地保留數據，並且支持應用程序中的「舊」定義作爲一種向後兼容的選項。換句話說，你正在做這些翻譯，而不是永久性的一次性更新。

這是不是真的有一個SQL數據庫的選擇，因爲你必須保持過時的列上，並可能索引。使用DODB，您並不是真的在浪費任何數據或索引空間。你必須權衡利弊。

主要缺點是，很明顯，不一致，這可能會隨時間增長而導致的錯誤。另一個缺點是可能在運行中執行此操作的計算花費，或者無法有效使用新結構（例如，您可能只想索引lastname）。所以，大多數情況下，我想我會選擇進行大規模更新。

然而，保留舊文件有一個明顯的優勢，如果你不能確定你的重構是完美的 - 例如，如果你的name列中的數據並沒有遵循一致的約定，也許在某些情況下，它的lastname, firstname而在其他情況下，它是firstname lastname而在其他情況下，它是company name - 那麼在不進行永久更新的情況下即時進行轉換可以讓您隨時間改進地圖，因此您可以在可用時使用firstname和lastname字段，但可以回退到遺留數據的猜測遊戲name。

如前所述，我大概預留特殊情況下，我不相信，我就可以得到「重構」正確的每個記錄/文檔第二個選項。儘管如此，這是一個對您而言可用的選項，您並不具備其他類型的數據庫。

除了這兩個，我沒有看到任何其他明確的選擇。這是一個二元決定。要麼永久更新現有數據，要麼不要。