为什么面向对象的数据库失败了？ [关闭]答案

【问题标题】：Why did object oriented databases fail? [closed]为什么面向对象的数据库失败了？ [关闭]
【发布时间】：2009-07-15 12:43:47
【问题描述】：

为什么面向对象的数据库失败了？

我觉得很惊讶：

foo bar = new foo();

bar.saveToDatabase();

输给：

foo bar = new foo();
/* write complicated code to extract stuff from foo */
/* write complicated code to write stuff to database */

Object Oriented vs Relational Databases

Why have object oriented databases not been successful (yet)?

【问题讨论】：

这可能有点主观/煽动性。维基？
值得注意的是，即使没有 OO 数据库，您的示例代码的第一个 sn-p 现在仍然很有可能使用诸如 Hibernate 之类的 ORM 解决方案（尽管我很欣赏样板代码仍然存在于某处...)
使用 ORM 并从此过上幸福的生活

标签： database

【解决方案1】：

可能是因为它们与特定的编程语言相结合。

【讨论】：

好点。许多数据库需要被广泛的应用程序访问。
这是一种很好的架构，可以解耦数据和编程语言。我讨厌在几个应用程序之间共享数据库。数据层业务逻辑过多。

【解决方案2】：

首先，我不相信他们已经完全“失败”了。目前仍有一些，据我所知，它们仍然被几家公司使用。

无论如何，可能是因为我们想要存储在数据库中的很多数据本质上都是关系型的。问题是，虽然是的，OO 数据库更容易集成到 OO 编程语言中，但关系数据库更容易定义查询以及存储数据之间的关系。这通常是复杂的部分。

【讨论】：

如果我使用 OO 语言（Java 或 C#）进行编码，我拥有哪些本质上是关系的数据？一切都在一个对象中。
仅仅因为一切都是编程语言中的对象并不意味着它也应该是数据库中的对象。您可能想要执行不直接映射到对象结构的查询。或者，您可能将来自多个不同对象模型的数据存储到同一个数据库中。在不同的应用程序中，您可能有不同的对象表示相同的数据。
Datomic 可以被视为对象数据库，只是不是第一代。

【解决方案3】：

我最近在我的个人宠物项目中一直使用db4o（一个面向对象的数据库），只是因为它的设置和启动速度非常快。不需要繁琐的细节。

除此之外，在我看来，它们没有流行起来的主要原因是：

在面向对象的数据库上报告更加困难。与此相关的是，手动查看关系数据库中的实际数据也更容易。
Microsoft 和 Oracle 的大部分业务都建立在关系数据库之上。
许多企业已经建立了关系数据库。
IT 部门通常具有关系数据库专业知识。

而且，正如 Jan Aagaard 所指出的，最近这是因为问题已经以不同的方式解决了，即使他们针对关系数据库进行编程，也给程序员一种面向对象的感觉。

【讨论】：

+1 报告和 IT 部门喜欢他们所知道的东西

【解决方案4】：

有无数的现有应用程序将其数据存储在关系数据库中。这些数据是这些公司的命脉。他们共同投入巨资来存储、维护和报告这些数据。将这些无价的信息转移到完全不同的环境中的成本和风险非常高。

现在考虑 ORM 工具可以将现代应用程序数据结构映射到传统的关系模型中，并且您几乎消除了迁移到 OODBMS 的任何动机。它们为非常昂贵的高风险迁移提供了一种低风险替代方案。

【讨论】：

InterSystems M 于 1979 年问世，正好是 Oracle 发布第一个 RDBMS 的同一年。我认为问题更多的是为什么 ODBMS 在 80 年代失败了。

【解决方案5】：

因为，尽管 ODBMS 广告中充斥着关于 ORM 系统的贬损语言，所以让 ORM 完成这项工作并不难，而且在切换到纯 ODBMS 时不会受到各种影响。

实际发生的情况是您的第一个代码示例获胜，它恰好位于 RDBMS 持久层上。

【讨论】：

【解决方案6】：

我认为这是因为问题的解决方式不同。当您在 Ruby on Rails 或 LINQ to SQL 中编码时，您可能会在幕后使用关系数据库，但感觉就像是在处理对象。

【讨论】：

【解决方案7】：

非常主观，但我想到了几个原因：

性能不如关系数据库（或者至少是这样的看法）
再次与性能有关 - 关系数据库允许您执行非规范化数据等操作以进一步提高性能。
对所有需要访问数据的非 OO 应用的旧版支持。

【讨论】：

斯坦福直线加速器中心显然拥有世界上最大的数据库，它是一个面向对象的数据库。也许我错了，但对我来说，这间接说明了性能。

【解决方案8】：

我认为您的很多答案都在于“面向对象与关系数据库”的“我们为什么放弃对象数据库”的答案。

就您的示例而言，不一定是那样。 Linq to SQL 实际上是 DBMS 上一个相当不错的基础层，Linq to Entities（v2 -- v1 很烂）也会很酷。 (N)Hibernate 多年来一直在使用 RDBMS 解决您遇到的问题。

所以我想我对你的回答是，O/R 映射器正在达到很好地解决你的问题的地步，你不需要 ODBMS 来获得你需要的东西。

【讨论】：

【解决方案9】：

他们总有一天会成功。他们是未来。

回顾历史上的软件技术，趋势是牺牲性能来降低复杂度（Assembly => C => C++ => .NET）。一个应用程序现在需要 30 分钟编码，过去几天需要一个月。

ORMs 是对错误问题的正确答案。目前，它们是选择，因为在没有更好的解决方案的情况下，它们让生活更轻松。但他们无法处理他们想要达到的复杂程度。 “问题无法通过创造它们的相同水平的思维来解决。”A.E

正如其他人提到的，关系数据库被大量使用和依赖，替换它们会带来很多风险。查看 SQL 版本之间的间隔以及这些版本与其他 Microsoft 产品之间的主要变化（保守的方法，这里是必要的）。此外，我将添加以下项目：

目前的方法仍然有效。您可能会争辩说它将永远有效（我们可以编写汇编代码），但在这里我的意思是它没有当项目复杂性的平均水平和是时候在关系数据库上开发它们了。
主要公司没有认真参与。当市场发出信号时，它们就会发出信号。
问题尚未明确定义。不幸的是，当前的故障有所帮助。
它需要在其他科学方面进行一些改进（QC、AI），而不是电脑。在平面上存储和查询多维数据基础设施和没有足够的智能来进行自组织是理论层面的最大障碍。

【讨论】：

【解决方案10】：

为什么不呢？

我想它们是解决没有人遇到的问题的解决方案，或者没有足够的钱来支付。

【讨论】：

【解决方案11】：

此外，OOP 和基于集合的编程并不总是非常兼容。就个人而言，当我开始阅读 OO 数据库时，我忍不住想：“男孩，我希望我永远不必处理其中一个，从 600 万行表中更新 100 万行，然后确保所有适当的记录在其他表中也得到更新”

【讨论】：