關系數據庫定義的結構非常嚴格，并且也通過嚴格的方式維護軟件應用程序的數據。Apache 的開源 CouchDB 為儲存數據提供一種新方法，即使用不需要模式的面向文檔的數據庫模型。與關系模型高度結構化的數據儲存不同，CouchDB 使用基于 JavaScript 的視圖模型生成結構化聚合，以半結構化的方式儲存數據，并從這些半結構化文檔報告結果。CouchDB 一開始是以 Web 應用程序為主要目標而開發的，并且希望發展成為用于開發 Web 應用程序的標準數據庫。
什么是 CouchDB？
CouchDB 是一個開源的面向文檔的數據庫管理系統，可以通過 RESTful JavaScript Object Notation (JSON) API 訪問。術語 “Couch” 是 “Cluster Of Unreliable Commodity Hardware” 的首字母縮寫，它反映了 CouchDB 的目標具有高度可伸縮性，提供了高可用性和高可靠性，即使運行在容易出現故障的硬件上也是如此。CouchDB 初是用 C++ 編寫的，但在 2008 年 4 月，這個項目轉移到 Erlang OTP 平臺進行容錯測試。
CouchDB 可以安裝在大部分 POSIX 系統上，包括 Linux® 和 Mac OS X。盡管目前還不正式支持 Windows®，但現在已經著手編寫 Windows 平臺的非官方二進制安裝程序。CouchDB 可以從源文件安裝，也可以使用包管理器安裝（比如在 Mac OS X 上使用 MacPorts）。
CouchDB 是一個 Apache Software Foundation 開源項目，根據 Apache 許可 V2.0 發布。這個開源許可允許在其他軟件中使用這些源代碼，并根據需要進行修改，但前提是遵從版權需知和免責聲明。與許多其他開源許可一樣，這個許可允許用戶根據需求使用、修改和分發該軟件。不一定由同一個許可包含所有修改，因為我們僅維護一個 Apache 代碼使用許可需知。
面向文檔的數據庫和關系數據庫之間的區別
對很多人而言，剛接觸面向文檔數據庫管理系統這個概念時很難理解它，尤其是長期與關系數據庫打交道的人員。這是因為這兩個模型相似的地方很少。
顧名思義，面向文檔數據庫是由一系列自包含的文檔組成的。這意味著相關文檔的所有數據都儲存在該文檔中 — 而不是關系數據庫的關系表中。事實上，面向文檔的數據庫中根本不存在表、行、列或關系。這意味著它們是與模式無關的；不需要在實際使用數據庫之前定義嚴格的模式。如果某個文檔需要添加一個新字段，它僅需包含該字段，從而不影響到數據庫中的其他文檔。因此，文檔不必為沒有值的字段儲存空數據值。
即將推出的書 CouchDB: The Definitive Guide（見 參考資料）使用名片作為 “現實的文檔”，并介紹了與關系數據庫相比，如何在面向文檔的數據庫中描述它。在關系數據庫中，您需要使用 4 個以上的表來儲存這些數據：一個 “Person” 表、一個 “Company” 表、一個 “Contact Details” 表和一個用于儲存名片本身的表。這些表都有嚴格定義的列和鍵，并且使用一系列的連接（join）組裝數據。
雖然這樣做的優勢是每段數據都有一個惟一真實的版本，但這為以后的修改帶來不便。此外，也不能修改其中的記錄以用于不同的環境。例如，一個人可能有傳真號碼，而另一個人沒有。在名片上不應該顯示 “傳真：沒有”，而是忽略任何關于傳真的細節。
在面向文檔的數據庫中，每個名片都儲存在各自的文檔中，并且每個文檔都可以定義它需要使用的字段。因此，對于沒有傳真號碼的人而言，不需要定義傳真的值，而對于有傳真號碼的人，則根據他們的意愿定義該值。
這兩種數據庫的另一個不同點是惟一標識符的儲存。在關系數據庫中通常可以使用主鍵，它由一個自動遞增特性或序列生成器生成。當然，這些標識符僅相對于所使用的表或數據庫是惟一的 — 其他表或數據庫還可以使用它們。如果同時對不同網絡上的兩個數據庫執行更新操作，這兩個數據庫不會同時準確地獲取下一個惟一標識符。CouchDB 沒有自動遞增或序列特性。相反，它為每個文檔分配一個通用惟一標識符（Universally Unique Identifier，UUID），這杜絕了其他數據庫意外地選擇相同的惟一標識符的情況。
面向文檔數據庫和關系數據庫的另一個重要區別是面向文檔數據庫不支持連接。因此 CouchDB 中沒有主鍵和外鍵，沒有基于連接的鍵。這并不意味著不能從 CouchDB 數據庫獲取一組關系數據。一個稱為視圖的特性允許您為沒有在數據庫中定義的文檔創建一種任意關系。這意味著您能夠獲得典型的 SQL 聯合查詢的所有好處，但又不需要在數據庫層預定義它們的關系。
一定要注意，雖然面向文檔數據庫的操作方式不同于關系數據庫，但這并不意味著它們是可以替換的。CouchDB 的目的并不是替換關系數據庫，而是為那些更適合使用面向文檔模型（而不是傳統的關系數據模型）的項目提供一種選擇，比如 wikis、博客和文檔管理系統。
