爲什麼OODBMS不像RDBMS那麼普遍？

Question

爲什麼關係數據庫比面向對象的數據庫更普遍？

如果面向對象的編程範例如此廣泛，我們不應該看到很多OODBMS嗎？它們不會比RDBMS + OR/M更好嗎？

Answer 1

RDBMS保持流行的一個原因是，它建立的技術很好理解，並且具有多個供應商支持的標準語言（SQL）。它還有一些好的接口，如ODBC和JDBC，可以很好地連接不同的語言。穩定的API是保持技術優勢的有力因素。

相比之下，OODBMS沒有明確的模型，也沒有標準語言，也沒有標準的API。通過實施領先的供應商，甚至沒有事實上的標準。

OODBMS概念可能表現比RDBMS + ORM更好。這完全取決於實施。但是，OODBMS並不能解決RDBMS擅長解決的同樣一組問題。如果您具有數據管理解決方案強制的參照完整性和關係頭，則某些數據管理任務更容易。 OODBMS模型中缺少這些功能（至少目前爲止）。

博客上有很多噪音，關係數據庫已經過時，但RDBMS仍然是絕大多數數據管理任務的最佳通用解決方案。

Answer 2

我認爲這是如果不破不改變它的

的情況下。

關係數據庫非常根深蒂固。

Answer 3

在（上週五晚上<摹>大詞）

大多數企業一個字互操作性與RDBMS上運行原有系統的工作。如果他們要使用OODBMS，他們仍然需要訪問RDBMS來執行某些功能。維護一種訪問數據的方式比兩種更容易。

當您在OODBMS世界擁有像Oracle和SQL Server這樣的大公司，並在各種環境中獲得可靠的性能時，那麼您會看到更多使用它們的項目。

Answer 4

數據通常壽命更長，比程序更重要。所以，即使你今天開始一個綠地開發，你也必須考慮整體情況。 RDBM系統有更多的工具，流程和經驗豐富的人員。除了能力計劃，數據挖掘，報告，ETL，與其他數據源的整合等方面，您還可以思考一下，您的公司如何收購另一家公司，從而將所有關係數據納入您的項目中。 RDBMS和相關工具是如此根深蒂固，被證明是有力的，所以我沒有任何其他策略意義。 在一些小的利基，也許但不一般。

Answer 5

對象數據庫對於代表幾何圖形等問題具有非常好的利基。 CAD系統，其中對象圖的確可能非常深刻。在大多數關係系統中，JOIN性能會迅速降低大約7個表，因此CAD中的深度自引用結構在對象數據庫中表現更好。

但重要的應用，如財務數據借給自己的關係表示。關係模型具有堅實的數學基礎，SQL是一種成功和流行的語言。像銀行，券商和保險公司這樣的金融機構沒有什麼動力從RDBMS中轉移出去。

Answer 6

我看到的最大問題是缺乏標準化。在RDBMS世界中，如果您知道SQL，那麼您可以隨意使用任意隨機數據庫。他們基本上都實現了它，只有很小的變化。我不知道一個現有的不執行SQL的RDBMS：您幾乎可以互換使用「RDBMS」和「SQL」。

一個OODBMS最接近的事也許是OQL，這一直是一個徹底的失敗。

沒有數據庫曾經實現過很多。幾年前，我使用了一個相當不錯的商業OODBMS，但是（截至2007年左右，主要版本爲8或9），它甚至不支持通過名稱查詢對象。該手冊簡單地說，這部分OQL他們還沒有得到。 （我不知道，但你可能已經能夠下拉到本機調用做到這一點。）

大多數對象數據庫我看到最近有本地語言的接口，而不是像OQL查詢語言。例如，我使用的系統支持（僅限！）Perl和VB，IIRC。限制你的聽衆只能使用兩種語言（或者像我們那樣強迫他們寫封裝）並不是贏得朋友的方式。

正因爲如此，有沒有競爭，因此不容易的備份計劃。如果您將數據置於MS-SQL中並且Microsoft停止支持它，則可以將數據轉儲到Postgres並移植查詢，而不會造成太大麻煩。 （如果你有很多疑問，可能會做很多工作，但我並不懷疑你可以做到這一點，這是一種痛苦，但在技術上並不具有挑戰性）。或者Oracle或MySQL或許多其他的商業並免費。

OODBMS不存在這樣的事情：如果你使用的那個人肚子痛，或者他們對你沒有用的方向，或者你覺得它缺乏你需要的關鍵功能，你可以只是將您的數據轉儲到競爭的OODBMS中並移植您的查詢。相反，你正在談論改變核心庫並進行大規模的體系結構變更。所以現實地說，你僅限於一個你真正信任的商業OODBMS（你能說出一個名字嗎？），或者是一個開源的OODBMS，當事情變糟時，你信任你的團隊維護它。

如果這聽起來像FUD，對不起，我不打算說。但是我一直在那裏，並且從項目管理的角度來看，即使編程環境可以很美妙，我也會猶豫回去。另一種思考它的方法是：看看今天多麼流行的函數式編程，儘管它是一個好主意。 OODBMS就是這樣，但更糟的是，因爲它不僅僅是你的代碼，還有你的代碼和你的數據。我很樂意今天在Erlang開始一個重要項目，但我仍然猶豫使用OODBMS。

面向對象數據庫廠商：改變這一點，你需要make it easy to leave you for your competitors。您可以挖掘OQL並實際實現它，或者在API級別（如ODBC）或任何其他位置執行該操作。即使是標準的轉儲格式（使用JSON？），以及用於將數據導入/導出到多個OODBMS的工具，也是一個很好的開始。

Answer 7

對於trival示例OODB和RDB可能會有很大的不同。特別是如果您使用的數據量足夠小，您可以一次性將所有數據全部讀入內存並一次寫出所有數據。但最終OODB需要以非常類似RDB的格式保存數據 - 它們並沒有太大的差別。

考慮可能在應用程序中使用的對象的任意圖形。每個對象可能被其他幾個對象引用。保存對象圖形時，您不希望每次引用對象時都重複保存對象。首先，如果你有任何一種循環或自我引用，你的保存對象方法會進入無限循環。但在一般情況下，這是浪費空間。相反，任何重要的數據存儲都需要爲每個要存儲的對象（一個關鍵字，通常是RDBMS中的代理關鍵字）聲明唯一標識符。引用它的每個其他對象保存對象類型和鍵，它不會重複保存整個對象。所以在這裏我們已經在我們的非RDB對象存儲中重新創建了外鍵。

接下來假裝我們要存儲與另一個對象（B）相關的對象列表（A1，A2，A3 ...）。我們已經確定我們將存儲密鑰而不是將對象本身保存兩次。但是，您是否將鍵存儲在對象B上的對象A1，A2，A3 ...上，或者是否將鍵存儲在對象B上？如果您以第一種方式存儲它們，並且您擁有所需的全部A，則可以快速獲取相關的B。第二種方式是相反的。但無論哪種方式都是單向交易。如果你想查詢你存儲的內容和你的對象存儲爲XML或JSON的相反情況，那麼通過大多數不相關的信息來解析每個文件中的密鑰是非常低效的。將它們以每個字段分開的格式（比如表格中的列）存儲起來會不會更好？

在多對多關係中，或者需要在兩個方向上查找大量對象的情況下，此策略變得非常低效。唯一的高性能解決方案是創建一個幫助對象來存儲關係，每個關係有一個文件，這樣該文件由A的鍵和B的鍵組成，以便快速查找它們。我們剛剛重新創建了交叉引用表。

帶有列，唯一標識符（鍵），交叉引用表的表格......這些是存儲對象的基本需求，以便可以高效地檢索對象。嗯...這聽起來像什麼熟悉的？關係數據庫提供了這個功能。此外，多家供應商已經競爭了數十年，以提供最快速的數據存儲和檢索功能，並提供備份，複製，羣集，查詢等最佳工具。這對於一種可與之競爭的新技術來說非常重要。最後，我說的是RDBMS基本上是解決高效對象存儲問題的一個非常好的解決方案。

這就是爲什麼像Hibernate這樣的東西存在 - 把面向對象的接口放在高效的RDBMS存儲系統上。當你看到其他類型的存儲的真正出色的是不同的問題領域：

• 對於任何類型的非結構化文檔存儲（博客，源代碼控制，或任何不能映射到行和列），各種NoSQL數據庫是理想
• 保留一個易於查詢但有意義的更改歷史記錄（如源代碼控制中的差異）在RDB中並不十分漂亮。像Datomic這樣的東西可能會在這裏形成新的領域。
• 任何時候你的對象圖是簡單的還是小的，數據庫的開銷都不是必需的。

OODBs不能比RDBs表現得更好，因爲它們沒有根本的不同。
RDBs在這裏留下來，因爲以節省空間和檢索的節省空間和節省時間的方式保存大型對象圖，並且還具有容錯能力並且有一定的數據完整性保證，這是RDB設計爲首先解決。這就是爲什麼JPA和Hibernate在這裏保持原樣 - 因爲它們彌合了對象和關係數據模型之間的差距。易於在內存中操作的對象模型，以及持久性的關係。