为什么关系数据库比面向对象数据库更常见？
如果面向对象编程范式如此广泛，我们难道不应该看到很多 OODBMS 吗？他们不会比 RDBMS+OR/M 表现更好吗？
14107 次
9 回答
37
RDBMS 保持流行的一个原因是它是成熟的技术，易于理解，并且具有多个供应商支持的标准语言 (SQL)。它还有一些很好的接口，比如 ODBC 和 JDBC，可以很好地与不同的语言连接。稳定的 API 是保持技术主导地位的重要因素。
相比之下，OODBMS 没有明确的模型，也没有标准的语言，也没有标准的 API。拥有领先的供应商实施甚至没有事实上的标准。
OODBMS 概念可能比 RDBMS+ORM 执行得更好。这完全取决于实施。但是，OODBMS 不能解决 RDBMS 擅长解决的同一组问题，这也是事实。如果您具有数据管理解决方案强制执行的引用完整性和关系标头，则某些数据管理任务会容易得多。这些特性在 OODBMS 模型中是不存在的（至少到目前为止）。
博客上有很多关于关系数据库已过时的噪音，但 RDBMS 仍然是绝大多数数据管理任务的最佳通用解决方案。
于 2009-08-29T01:23:50.733 回答
21
我见过的最大问题是缺乏标准化。在 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 犹豫不决。
OODBMS 供应商：要改变这一点，您需要让竞争对手轻松离开您。您可以挖掘 OQL 并实际实现它，或者在 API 级别执行它，如 ODBC 或其他。即使是标准的转储格式（使用 JSON？），以及用于几个 OODBMS 的导入/导出工具，也将是一个很好的开始。
于 2009-11-14T22:34:52.290 回答
16
数据通常比程序寿命更长，而且更重要。因此，即使您今天开始进行绿地开发，您也必须考虑整体情况。有更多的工具、流程和经验丰富的人员使用 RDBM 系统。超越计划，想想容量规划、数据挖掘、报告、ETL、与其他数据源的集成等。您的公司如何收购另一家公司，从而将他们所有的关系数据带入您的计划。RDBMS 和相关工具是如此根深蒂固、经过验证且功能强大，以至于我在使用其他任何东西时都没有任何战略意义。在一些小的利基市场中，也许但不是一般的。
于 2009-08-29T01:04:51.647 回答
6
对象数据库对于表示几何等问题有一个非常好的利基，例如 CAD 系统，其中对象图确实可以非常深。在大多数关系系统中，大约 7 个表的 JOIN 性能迅速下降，因此 CAD 中的深度自引用结构在对象数据库中的性能更好。
但是像财务数据这样的重要应用程序适合于关系表示。关系模型具有坚实的数学基础，SQL 是一种成功且流行的语言。银行、经纪公司和保险公司等金融机构几乎没有动力放弃 RDBMS。
于 2009-08-29T02:28:45.830 回答
4
对于简单的示例，OODB 和 RDB 可能非常不同。特别是如果您使用的数据量足够小，您可以轻松地将其一次全部读入内存并一次全部写出。但最终 OODB 需要以非常类似于 RDB 的格式保存数据——它们并没有太大的不同。
考虑可能在应用程序中使用的任意对象图。每个对象都可以被其他几个对象引用。保存对象图时，您不希望每次引用对象时都重复保存对象。一方面，如果您有任何类型的循环或自引用，您的保存对象方法将进入无限循环。但在一般情况下，这是浪费空间。相反，任何重要的数据存储都需要为每个正在存储的对象声明一个唯一标识符（一个键，通常是 RDBMS 术语中的代理键）。引用它的每个其他对象都会保存对象类型和键，它不会重复保存整个对象。所以在这里我们在我们的非 RDB 对象存储中重新创建了外键。
接下来，假设我们要存储与另一个对象 (B) 相关的对象列表 (A1、A2、A3...)。我们已经确定我们将存储密钥而不是两次保存对象本身。但是，您是将对象 A1、A2、A3... 的密钥存储在对象 B 上，还是将对象 B 的密钥存储在 A 上？如果你用第一种方式存储它们，并且你拥有所有你想要的 A，你可以快速获取相关的 B。第二种方式反之亦然。但无论哪种方式都是单向交易。如果您想查询您存储的内容的相反内容并且您的对象存储为 XML 或 JSON，那么通过大多数不相关的信息来查找每个文件中的键是很多低效的解析。将它们以每个字段分开的格式存储不是更好吗，就像表中的列？
在多对多关系中，或者需要在两个方向上查找大量对象的情况下，这种策略变得非常低效。唯一有效的解决方案是创建一个帮助对象来存储关系，每个关系都有一个文件，这样文件由 A 的键和 B 的键组成，以便可以快速查找它们。我们刚刚重新发明了交叉引用表。
具有列的表、唯一标识符（键）、交叉引用表……这些是以可以有效检索的方式存储对象的基本需求。嗯……这听起来是不是很熟悉？关系数据库正好提供了这个功能。此外，数十年来，多家供应商一直在竞争，以提供最快的数据存储和检索以及用于备份、复制、集群、查询等的最佳工具。这对于一项新技术来说是一个很大的竞争。最终我要说的是，RDBMS 基本上是解决高效对象存储问题的一个非常好的解决方案。
这就是存在 Hibernate 之类的东西的原因——将面向对象的接口放在高效的 RDBMS 存储系统上。您看到其他类型的存储真正大放异彩的地方是不同的问题领域：
- 对于任何类型的非结构化文档存储（博客、源代码管理或任何无法映射到行和列的东西），各种 NoSQL 数据库都是理想的
- 保持易于查询但有意义的更改历史记录（如源代码控制中的差异）在 RDB 中并不是很漂亮。像 Datomic 这样的东西可能正在这里开辟新的领域。
- 任何时候你的对象图很简单或很小，数据库的开销可能不是必需的。
OODB 不能比 RDB 表现得更好，因为它们并没有根本不同。
RDB 将继续存在，因为以一种既节省空间又节省时间的方式保存大型对象图以进行保存和检索，并且具有容错性并具有一定的数据完整性保证是 RDB 旨在解决的问题第一名。这就是为什么 JPA 和 Hibernate 也会继续存在的原因——因为它们弥合了数据的对象模型和关系模型之间的差距。易于在内存中操作的对象模型，以及用于持久性的关系。
于 2012-12-03T14:50:05.303 回答
3
总之互操作性（周五晚上的大词 <G> ）
大多数企业必须使用在 RDBMS 上运行的遗留系统。如果他们要使用 OODBMS，他们仍然需要访问 RDBMS 才能执行某些功能。维护一种访问数据的方式比两种方式更容易。
当您在 OODBMS 世界中拥有像 Oracle 和 SQL Server 这样的大牌并在各种环境中得到证明的性能时，您将看到更多使用它们的项目。
于 2009-08-29T00:57:44.137 回答
0
我认为这是一个案例
如果它没有损坏，请不要更改它。
关系数据库非常根深蒂固。
于 2009-08-29T00:45:36.530 回答
0
主要问题是索引！
索引标量值真的很好……只是对它们进行排序。
对于具有许多属性、方法、部件、组件等的值……没有通用规则……。
所以 OODBMS 就像恐龙一样消失了！
但是 RDBMS 供应商集成了一些工具来在数据库中拥有对象，例如 XML（研究和开发有时会为特殊的真正使用的对象找到索引方法，但很难......），并且还支持任何类型的对象的存储（没有可能对其进行索引……）通常在 Java (Oracle) 或 .net (SQL Server) 中。
于 2020-01-11T11:02:28.833 回答
-1
对于为什么关系数据库比对象数据库更常见的问题，最直接的答案是大多数问题都可以使用关系数据库来解决。绝大多数人每天都有一套特定的工具来解决他们遇到的几乎所有问题。程序员也是如此。许多程序员只需要一个关系数据库，因此关系数据库市场可以为他们服务。
但是，如果您为 CAD/CAM/CAE 行业开发软件，或者如果您开发链接分析应用程序以支持调查，或者如果您构建复杂的数据融合系统，您的工具箱中可能有一个对象/图形数据库，因为它们执行在这些领域比关系数据库好得多。
免责声明：我在 Objectivity, Inc. 工作，我们在那里生产、营销和销售可大规模扩展的分布式对象/图形数据库。
于 2021-03-07T21:21:55.657 回答