基於文檔的數據庫與關係型數據庫的優缺點

我一直在試圖查看是否可以用基於文檔的數據庫來完成一些要求，在這種情況下是CouchDB。兩個通用要求：實體的一些領域具有獨特的指數上基於文檔的數據庫與關係型數據庫的優缺點

電子商務Web應用程序像eBay（better description here）

CRUD。

而我開始認爲基於文檔的數據庫不是解決這些需求的最佳選擇。此外，我無法想象用於基於文檔的數據庫（可能我的想象力太有限）。

您能否向我解釋一下當我嘗試使用面向文檔的數據庫滿足這些要求時，我正在從榆樹詢問梨？

來源

2008-12-03 user2427

「從榆樹問梨」=問不可能。（傑森的鏈接已經死了。） – Dennis 2012-08-21 16:34:28

基於文檔的數據庫最適合存儲文檔。 Lotus Notes是一個常用的實現，Notes郵件就是一個例子。對於您所描述的，電子商務，CRUD等，實際數據庫更適合存儲和檢索索引的數據項/元素（與文檔相對）。

來源

2008-12-03 14:57:27

我不同意。文檔數據庫主要不用於存儲文檔。它用於存儲分層的數據片段（JSON或XML）。您可以使用例如MongoDB爲嵌套的JSON字段和JSON數組編制索引。您可以將文檔（文件）存儲在MongoDB（gridfs）中，但是如果您無法使用MongoDB存儲文檔（文件），MongoDB仍然很有用。我認爲應該將MongoDb稱爲JSON數據庫而不是文檔數據庫。 – Theo 2010-05-19 15:12:58

根據維基百科對「面向文檔的數據庫」的條目，「...使用XML，YAML或JSON進行信息存儲具有類似於面向文檔的數據庫的優點」，但它們不是同一回事。文檔數據庫最初是爲存儲文檔而設計的。如果您將它們用於其他數據，則不會像將文檔存儲在關係數據庫中那樣獲得最佳性能/使用率。這發生了很多。人們在文檔數據庫中存儲關係數據，然後抱怨文檔數據庫有多糟糕。如果你濫用它們，是的。 – 2010-05-28 16:30:11

維基百科條目http://en.wikipedia.org/wiki/Document-oriented_database已更新，值得一看，以確認面向文檔的數據庫的確比文檔櫃實際更多。 – 2010-11-10 16:37:46

您需要考慮如何以面向文檔的方式處理應用程序。如果您只是試圖複製如何在RDBMS中對問題進行建模，那麼您將會失敗。您也可能想要做出不同的折衷。（[編輯：不知道這是如何與參數聯繫起來的，但是：]請記住，CouchDB的設計假設您將有一個可能隨時會失敗的許多節點的活動集羣。您的應用程序如何處理從其中消失的一個數據庫節點在它下面？）

想一想的一種方法是想象你沒有任何電腦，只是紙質文件。您如何使用傳遞的紙張創建高效的業務流程？你怎樣才能避免瓶頸？如果事情不順利怎麼辦？

你應該考慮的另一個角度是最終的一致性，最終會達到一致的狀態，但是在某段時間你可能會不一致。這在RDBMS領域是詛咒，但在現實世界中非常普遍。規範交易的例子是從銀行賬戶轉賬。這在現實世界中是如何發生的 - 通過單個原子交易或通過不同的銀行向對方發放信用卡和借記通知？當你寫支票時會發生什麼？

所以讓我們看看你的例子：實體

CRUD與它唯一索引某些字段。

如果我在CouchDB條款中正確理解這一點，那麼您希望擁有一組文檔，其中某些命名值在所有這些文檔中都是唯一的？這種情況通常不受支持，因爲文檔可能在不同的副本上創建。

所以我們需要看看現實世界的問題，看看我們是否可以建模。你真的需要他們是獨一無二的嗎？您的應用程序可以使用相同的值處理多個文檔嗎？你需要分配一個唯一的標識符嗎？你能確定地做到這一點嗎？在需要這種情況的常見情況下，您需要一個唯一的順序標識符。在複製的環境中這很難解決。事實上，如果要求唯一身份證件嚴格按照創建的時間順序執行，那麼不可能如果您需要馬上使用身份證件。你需要放鬆至少其中一個限制。像eBay

電子商務的Web應用程序，我不知道該怎麼在這裏添加爲最近一次所做的那個帖子是說「非常有用！謝謝」的評論。在那裏概述的方法中是否存在某些仍然會導致問題的東西？我認爲庫爾特先生的回答非常充分，我增加了一點可以減少爭用的增強功能。

來源

2008-12-03 16:49:00 Kerr

如何使用UUID分配無共享全局唯一標識符？人們通常在文檔數據庫世界中做到這一點嗎？ – 2011-09-27 17:56:18

是否需要規範化數據？

是：使用關係。
否：使用文檔。

來源

2008-12-03 16:52:27 dacracot

一種可能性是有一個主要的關係數據庫，它存儲可以通過它們的ID檢索的項目的定義以及用於這些項目的描述和/或規格的文檔數據庫。例如，你可以有一個關係數據庫產品表具有以下字段：

的ProductID
說明
單價
LotSize
規格

這規格字段實際上會包含對具有產品技術規格的文檔的引用。這樣，你有兩全其美。

來源

2010-01-27 03:13:25 pyon

我在同一條船上，此刻我很喜歡couchdb，我認爲整個功能風格都很棒。但是，到底什麼時候我們開始將它們用於應用程序。我的意思是，是的，我們都可以開始非常快地開發應用程序，所有那些關於常規形式的討厭掛斷都會被遺忘，而不會使用模式。但是，要給出一句「我們站在巨人的肩膀上」。有一個很好的理由使用RDBMS並規範化和使用模式。我的老oracle頭正在思考無形式的數據。

我在couchdb上的主要因素是複製的東西和版本控制系統協同工作。

上個月，我一直在絞盡腦汁地試圖尋找couchdb的存儲機制，顯然它使用B樹，但不存儲基於正常形式的數據。這是否意味着它真的很聰明，並意識到數據的位被複制，所以我們只需要指向這個B樹條目？

到目前爲止，我正在考慮將xml文件，配置文件，資源文件流式傳輸到base64字符串。

但我會用couchdb來獲取結構數據嗎？我不知道，任何幫助非常讚賞這一點。

可能對於存儲RDF數據甚至自由格式文本很有用。

來源

2010-06-14 10:16:17 WeNeedAnswers

-1

Re CRUD：整個REST範例直接映射到CRUD（反之亦然）。因此，如果您知道您可以使用資源（可通過URI識別）和一組基本操作（即CRUD）對您的需求進行建模，那麼您可能非常接近基於REST的系統，其中很多面向文檔的系統提供的盒子。

來源

2011-12-06 15:35:24 KoW

基於文檔的數據庫與關係型數據庫的優缺點

回答

相關問題