文檔：CouchDB 數據庫的構建塊
CouchDB 數據庫存儲惟一的命名文檔并提供一個 RESTful JSON API，該 API 允許應用程序讀取和修改這些文檔。CouchDB 數據庫中的所有數據都儲存在一個文檔中，并且每個文檔可以由未定義的字段組成。這意味著每個文檔都可以具有未在其他文檔中定義的字段。換句話說，這些文檔不受嚴格的模式的限制。
每個文檔還可以包含元數據（關于數據的數據），比如惟一的文檔 ID 和修改號。文檔字段可以包含各種類型的數據，比如文本字符串、數字和布爾值（true/false）等。字段的大小不受限制。每個字段必須有一個惟一的名稱（文檔不能包含兩個同名的字段）。
當更改 CouchDB 文檔時，這些更改實際上并不是附加在原來的文檔之上，而是創建整個文檔的一個新版本，即 修訂。這意味著數據庫會自動維護文檔修改的完整歷史。文檔-修訂系統管理修訂控制，但不包括在數據庫中自動完成的修訂。
CouchDB 沒有鎖機制；兩個客戶機可以同時加載和編輯同一個文檔。不過，如果一個客戶機保存了所有更改時，另一個客戶機在嘗試保存更改時將收到一個編輯沖突�？梢酝ㄟ^加載更新版本的文檔來解決該沖突，然后重新進行編輯并再次保存。CouchDB 通過確保文檔全部更新成功或全部失敗來保持數據的一致性 — 文檔更新要么成功，要么失敗。數據庫中不會存在僅保存了一部分的文檔。
回頁首
視圖：從 CouchDB 獲取有用信息
CouchDB 的本質是非結構化的，雖然由于缺乏嚴格的模式而使其獲得了更大的靈活性和可伸縮性，但是這使得 CouchDB 在現實應用程序中難以使用。想一下關系數據庫，對于每個應用程序，嚴格定義的表之間的關系對于為數據賦予意義至關重要。不過，當要求實現更高的性能時，則需要創建物化視圖來反規范化（de-normalize）數據。在很多情況下，面向文檔數據庫采用相反的方法處理事情。它將數據儲存在一個平面地址空間中，這就像一個完全反規范化的數據倉庫。然后它提供一個視圖模型為數據添加結構，因此能夠聚合數據得出有用的含義。
在 CouchDB 中可以根據需求創建視圖，并使用它在數據庫中聚合、連接和報告文檔。視圖是動態創建的，對數據庫中的文檔沒有影響。視圖是在設計文檔中定義的，并且可以跨實例復制。這些設計文檔包含使用 MapReduce 運行查詢的 JavaScript 函數。視圖的 map 函數將文檔作為一個參數，并執行一系列的計算來決定應該對哪些數據使用視圖。如果一個視圖具有 reduce 函數，就使用它來聚合結果。視圖接收一組鍵和值，然后將它們合并成一個單一的值。
清單 1 是 CouchDB 視圖的 map 和 reduce 函數的一個例子，它計算帶有附件的文檔的數目。
清單 1. 典型的 CouchDB 視圖
map: function(doc) { if (doc._attachments) { emit("with attachment", 1); } else { emit("without attachment", 1); }}reduce: function(keys, values) { return sum(values);}
CouchDB 視圖可以是儲存在設計文檔內部的永久性視圖，或者是根據需求執行的臨時視圖。臨時視圖耗費的資源比較多，并且隨著數據庫中存儲的數據的增長而變慢。因此，CouchDB 視圖大部分情況下應該創建在設計文檔中。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
