關係陣營和「現實世界」數據庫開發

超過十年，因爲日期的首次出版，並通過更多達爾文的"The Third Manifesto" 1995年關係陣營和「現實世界」數據庫開發

什麼是思想的關係學在當今世界數據庫的地方？有沒有證據表明Manifesto的想法改變了主流軟件開發和數據管理實踐？他們是否催化了創建新的數據管理產品？這些產品是否商業上成功？

2008-09-27 Constantin

我們正在看到一些方法，即對象建模技術可以用於管理數據。我們有Linq和NHibernate，它允許我們將數據庫中的數據映射到代碼中的對象。然而。我認爲我們離真正面向對象的數據庫還有很長的路要走。我不知道我們會永遠。雖然使用「對象」具有優勢，但使用關係數據模型將數據視爲集合具有很多優點。

來源

2008-09-27 01:02:07 Kibbee

到目前爲止，似乎已經走出了OODBMSs不會有儘可能廣泛的採用一些想要他們，原因很簡單：只OODBMSs解決OOP開發者的關注，而不是其他人，這包括DBA，分析師，MIS專業人員以及大量不是面向對象的開發人員，而是「數據驅動」。

如此說來，企業數據的大量殘留在RDBMS中，以類似的方式企業數據的大量也保持在COBOL/CICS供電系統。

至於事實，你可以谷歌幾個小時尋找統計數據，但你不會找到任何。你會發現Oracle與MS SQL Server與MySQL/PostGre /其他開源RDBMS採用統計數據相互比較，而像db4o這樣的OODBMS在很大程度上被忽略。

來源

2008-09-27 01:20:36

確實如此，不要忘記列表中的用戶，審計員，senoir經理等。我的數據庫存儲了我工作的公司的整個生命線。 – HLGEM 2008-09-28 21:50:28

我一直處理的數據集太大認真考慮渲染數據包含所有的信息和方法來訪問數據元素類的經典的「對象」的模式/操縱它們。

但是我發現了一個簡單的與.NET數據集的妥協模型。由於它們「自我緩衝」到磁盤，它們對於處理可能會或可能不適合內存的大量數據非常有用 - 所以我將它們用於我的「對象集合」。

然後所有包含「業務」的對象應用程序的類只是在一個包含自己的信息和所有的類簡單地從記錄集解析方法，在數據集中的記錄的引用。

Works的查詢返回1個結果一百萬 - 和類模式很容易複製 - 因爲基本上所有的類的內部數據變量只是在記錄的字段。

來源

2008-09-27 01:25:29

在業務數據處理中，關係模型是穩固根深蒂固的，無法刪除。它是中心因素，通常會被濫用於不適當的事情。人們會使用（濫用）關係數據庫作爲可靠的消息隊列，因爲 - 他們將每個問題視爲數據庫問題。

關係模型是每個業務流程的許多（幾乎所有）商業產品的支柱。很難找到任何不具有根本關係的東西。事實上，在許多情況下，產品與數據庫密切配合。 Oracle的財務，微軟的Dynamics會計等。

在可預見的將來，關係數據存儲將成爲業務數據處理的主要存儲。

目前，關係數據庫不言而喻。每個人都會問「哪個數據庫引擎」，這樣他們就可以權衡Oracle與IBM，微軟與MySQL之間的爭論。沒有人會問「數據模型會是什麼？對象或關係？」

ORM將繼續取得進展。面向對象的編程將繼續增長，導致越來越多的ORM。突破這個框是困難的 - 幾乎不可能 - 因爲商業IT關注的是穩定性而不是創新。他們的目標幾乎總是「保持燈亮」。這意味着拒絕改變，直到供應商被迫停業或終止對產品的支持。

來源

2008-09-27 15:39:52

面向對象數據庫是一個矛盾。無論如何，越是嘗試創建面向對象的數據庫，越是在關係世界中最終結束。在我看來，他們只是炒作。請注意，ORM的不是OO數據庫。數據集也不是。我以前聽說過這個論點，所以我只是想說清楚一下。

來源

2008-09-27 16:11:32 Mladen

這就是第三個宣言的要點，我認爲：真正的關係數據庫系統（不是我們今天所擁有的）不需要任何OR映射，它根據定義支持對象。 – Constantin 2008-09-28 11:13:01

這些年來我見過很多關於OOD如何超越關係數據庫的討論。關係模型是過去的方式;從巨大的安裝基礎（電阻... 傳統）的慣性是妨礙OOD進展。「只要一個'足夠好的'實現終於出來併成功地破壞RDBMS，只是時間問題。」

我不是專家，但我已經想了很多次了，我認爲這些觀點完全錯過了這一點。

在大多數「現實世界」場景中，重要的是，唯一重要的是數據。

編程技巧，工具和語言的變化;技術發展。企業「語音應答系統」變得風靡一時，然後幾乎消失在「網絡」的陰影之後。應用程序來來去去;其中一些很好，一些不太好;一些關鍵的，有些僅僅是方便;一些最後3個月，一些最後的30年。但在一天結束時，提供所有這些應用程序的信息是系統的心臟，並且必須經受住時尚的波動。 數據保留。

因此，「系統」的核心必須圍繞這一目標發展：保持和保護數據。

想想看：在特定的SQL數據庫給我們一個自由站立，（大部分）有幾十年歷史的記錄證明標準庫，並可以用什麼，遠未過時的，本質上是功能隨時隨地訪問語言！這是一個相當不錯的地方去信任你最有價值的組件。

任何將編程工具，環境或應用程序的優先級放在將數據保存在模糊存儲區中的任何方法 - 任何將應用程序技術與數據綁定得太緊密的東西都可能會下降在路邊。

不是說我相信世界上的一切都必須進入SQL表格。類似OOD的解決方案也有一席之地，並且具有很大的潛力。但是您需要查看「應用程序」爲王，「數據」爲次要的地方：遊戲，一次性應用程序和工具，持有不重要數據或過去沒有長期價值的數據的系統應用程序的預期壽命。

特別是，我認爲具有有限使用壽命（最多幾年）的系統是類OOD技術的主要候選者。另一方面，當有一天需要將數據「交給」其後繼者的任何事情時，除了一個古老的RDBMS之外，我會非常遺憾的。

把它放在一個健全的字節裏，它從來不是關於「應用程序」的;它的總是一直關於「數據」。

來源

2008-09-28 04:07:45

好說！謝謝， – Sklivvz 2008-09-28 17:36:37

否通過雲計算的出現，支持者不一定以關係方式存儲數據，最近才發生了唯一明顯的變化。

來源

2008-09-28 17:17:42

關係陣營和「現實世界」數據庫開發

回答

相關問題