創建新文檔而不是在CouchDb中更新有什麼可能的缺點？

我已經開始在我的新項目中將CouchDb與PouchDb一起使用，並且對它來說是相對較新的。我有一個基本的疑問。創建新文檔而不是在CouchDb中更新有什麼可能的缺點？

要更新文檔，我需要有_rev值，這意味着查詢數據庫，例如，如圖here

// fetch mittens 
db.get('mittens').then(function (doc) { 
    // update their age 
    doc.age = 4; 
    // put them back 
    return db.put(doc); 
}).then(function() { 
    // fetch mittens again 
    return db.get('mittens'); 
}).then(function (doc) { 
    console.log(doc); 
});

更新後，有存在於分貝文檔的兩個版本。文檔的舊版本只在壓縮過程中清除。

如果我向我的文檔ID添加時間戳，例如 [email protected]，然後而不是有相同的文件的不同版本，我的數據庫中有不同的文件。

添加新文檔後，我可以使用較舊的時間戳刪除文檔。因此，當查詢我可以查詢all_doc與

startkey="[email protected]"&endkey="[email protected]\uffff"

並採取基於時間戳的最新文檔。（無論如何，由於我在創建新文檔時刪除了較舊的文檔，因此此查詢只返回一個文檔。）

在我構建的應用程序中，將創建和修改桌面應用程序文檔桌面，並同步到服務器進行倉儲/報告/分析。因此，其他人修改導致衝突的文檔的場景很少。

最初，我已經走了保持id相同的方法。但是，我在嘗試更新文檔時遇到了一個奇怪的錯誤，其中pocuhdb發生錯誤，但是在CouchDb上創建了具有相同數據的不同修訂版本，並將pouchDb配置爲同步數據。由於我缺乏時間並且正在構建概念驗證，所以我繼續在_id中使用時間戳。

但是，現在我想知道這種方法的潛在缺陷是什麼？我有一種直覺，因爲從哪裏我都看不到有人採用這種方法，但我不太確定他們是什麼。

來源

2016-06-01 shashi

這個關於CouchDb的10個常見誤解的談話實際上建議爲每個更改創建新的文檔https://youtu.be/BKQ9kXKoHS8?t=10m10s – shashi

CouchDb通過主ID查找效率最高。要使用開始和結束鍵，您需要使用視圖，這意味着您將失去性能並處理更復雜的視圖。

例如，如果您執行大量插入操作，從更新視圖獲取響應時會有小的延遲。它還需要更多的磁盤空間。

我還會爭辯說，您將執行的刪除操作會影響您的性能，而不是在更新之前先檢索文檔。最好在安靜的時候與舊版本進行壓縮處理。

最後，由於您總是創建新的文檔，我假設您在寫入時將始終可以訪問完整文檔（您將如何以其他方式存儲而無需檢索），也許您還可以存儲「_rev 「param（在執行PUT時返回），然後將其用於更新，而不必請求文檔。

來源

2016-06-02 20:22:53

Nicholaj是正確的：在你的特定情況下，創建新的每次更新的文檔，這隻會在許多用戶編輯同一文檔的環境中才有意義。您聽到的問題聽起來像是衝突，試圖解決衝突。 –

創建新文檔而不是在CouchDb中更新有什麼可能的缺點？

回答

相關問題