20

这就是问题所在。只给出一个你认为为什么 OODB 失败或者为什么现在许多系统仍然使用关系数据库的原因。

4

14 回答 14

24

主要原因是SQL。能够在应用程序之外的其他上下文中使用数据库中的数据是非常有用的，并且通常对于对象数据库，数据以不容易查询的格式存储。例如，使用关系数据库，数据可以成为数据仓库的一部分，或者只是由系统管理员查询等。

于 2008-10-04T17:13:46.463 回答
22

我们可以回答不止一次吗？另一个原因是关系数据库在数学上有坚实的基础：从关系的定义，一直到范式，理论都是坚如磐石的。确实，关系模型不能很好地映射到 OO，但恕我直言，该模型的好处和稳定性超过了映射问题。

于 2008-10-04T17:21:10.067 回答
13

我认为这是因为“对象数据库”正在解决（几乎）没有人真正遇到的问题。对于对象图的简单持久性，大多数 OO 环境中内置的序列化“足够好”。如果您想对数据的子集进行复杂的操作，那么关系数据库和 SQL 是完美的选择。

除了一些边缘应用程序（不能保存在内存中的巨大对象图，但关系不能很好地简化以供 RDBMS 使用）之外，确实不需要这些工具。

于 2008-10-04T17:39:57.283 回答
11

仅仅因为 OODB 不是主流，我们仍然应该考虑他们已经取得的成功。Cache 和 Zope 都被广泛使用（相对而言），但按照某些标准会被认为是成功的。

也许 OODB 没有显着占据主导地位的最大原因是混合对象关系系统的成功，这些系统从 OODB 中占据了大部分潜在市场份额：PostgreSQL 和 Informix。

我知道这并不能直接回答这个问题，但我认为它是等式的一部分。但总的来说，我认为支持关系数据库的势头和根深蒂固的思维过程使人们很难转换。目前，DB 专业几乎只接受过关系理论方面的培训，这使得您的 DB 专业人员对避免 OODB 非常感兴趣，而学术界几乎专门为从业者教授关系理论方面的 DB 理论。

在大型企业 DBA 和主流教授和课程以及开发人员以外的人员准备好管理 OODB 之前，我觉得无论从开发方面有多好，都不太可能看到大众吸引力。

于 2008-10-04T17:22:48.893 回答
8

嗯，很奇怪不是吗？作为面向对象分析和设计的顶峰，对领域驱动设计的推动如此之大，并且有企业模式可以利用 ORM 系统来持久化我们的对象。对我来说，如果您的应用程序设计本质上是面向对象且以领域为中心的，那么 OODB 将极大地有益于您的应用程序，这对我来说完全有意义。

除了围绕成熟度和采用的问题之外，从哲学的角度来看，OODB 似乎是有益的或 OO 应用程序。不必为初学者维护该映射层；）

但是看，如果您不进行域驱动设计并将对象用作数据对象并且像您的存储过程一样，那么您就不会真正得到它；）

于 2008-10-06T04:12:21.937 回答
5

RDBM（建立在强大的理论基础上，在市场上存在的时间要长得多，在许多情况下可以比 OODB 更忠实地建模数据，比 OODB 可以被更多的 DBA 使用）。这是关系元组形式的原因之一。

于 2008-10-04T17:45:03.047 回答
3

如果我可以放大 Phil 的观点：SQL 的标准化。OODB 曾尝试过诸如 OQL 之类的查询语言，但它们似乎从未遵循真正的标准。查询语言的质量也令人怀疑，可以说是由于缺乏标准化。标准促进竞争，从而产生质量。

于 2008-10-04T17:18:05.563 回答
3

原因之一是数据库是关于数据的，而对象是关于结构和算法的。一旦获取数据并将其嵌入类中，您就可以在静态结构中描述关系和操作。另一方面，数据库是将数据解构为一堆原子表实例，这些原子表可以重新组装成不同的结构（通常带有类），而不会干扰原子的完整性。

数据库有点类似于六边形。

于 2009-03-28T02:50:43.170 回答
2

那，还有 o/r-mappers。通过它们，与真正的 OO-DB 的差异变得更小，而上述好处仍然有效。

于 2008-10-04T17:18:07.653 回答
2

昂贵的技术决策不是由具有技术知识的人做出的。使用关系数据库的公司雇佣了很多人，他们感到受到 OODB 的威胁，因此会避免了解它们。

于 2011-05-10T23:22:43.107 回答
1

我认为有两个哲学原因。

首先，人们传统上倾向于将持久性与实际功能分开。一旦你把一个对象的“生命”从它身上剥离出来，并主要为了持久性而保留它，它就变成了一个记录，然后就有一种将它视为“没有生命”的数据对象的趋势。

此后，当人们想到大量非常相似的事物时，他们开始将它们视为表格而不是对象。

我认为 O/R 的区别开始消失。例如，我使用 hibernate 将非常复杂的类层次结构转储到 MySQL 数据库中。但是，我不会为我的项目编写性能关键的东西，所以我确信它没有有效地完成。

于 2008-10-04T19:04:44.880 回答
1

OODB 采用缓慢的原因主要基于使关系 SQL 数据库更流行和/或更合适的几个关键因素。虽然纯面向对象的数据库现在处于克服关系模型的许多缺点的状态，但仍然缺少一些关键部分。

一方面，他们往往缺乏对中央数据库管理的支持，尽管这正在迅速在各种产品中得到纠正。

第二个原因是很少有系统实现标准查询语言，而是依赖编程语言或专门的查询语言来检索和操作存储中的数据。如果他们必须在程序员习惯于基于 NoSQL 的解决方案的完全不同的思维方式之上学习一种新的查询语言，那么这对许多人来说是一个阻碍。最重要的是，大多数基于 SQL/关系的数据库现在都支持面向对象的设计，此外，我们还有像 ORM 这样的包装器，许多人使用这些包装器来“绕过”关系数据库在所选编程语言中不易使用的问题。

但这些问题大多存在于企业环境中。作为小型设备中的嵌入式数据库、网站存储以及航空航天等领域，它们已经变得非常流行，并且在许多情况下完全取代了对常规关系数据库的需求。

谁知道未来会怎样？

于 2013-10-30T22:16:54.153 回答
0

大多数语言提供的序列化使您可以展平对象属性，从而轻松地将它们存储到 RDBMS 中，并且类似地检索对象并不是一个大问题。仍然缺乏广泛而坚实的基础，这阻碍了OODBMS的使用得以实施。

我目前正在考虑将其作为我的硕士论文项目，为 OODBMS 提供一个通用框架，该框架支持现在 RDBMS 中常用的几乎所有组件，从而提供非线性结构化 DBMS。在学习期间，我遇到了一个名为 db4o 的项目，它是一种仅将 OODBMS 用于 Java 和 .net 的方法（已实现），因此这可能是所有类型的平台和语言缺乏通用性的另一个原因。

于 2014-02-18T19:21:07.930 回答
-1

我认为这是因为像甲骨文这样的大公司一直在投资关系数据库，而面向对象的运动正在获得动力……如果甲骨文/微软大举投资，它们可能会成为主流……这似乎不太可能，因为他们没有没有充分的理由这样做……它会简化许多程序员的生活……但是“让程序员的生活更简单”对他们来说并不是一个很好的商业目标！

于 2011-06-15T11:39:23.500 回答