关系型数据库比面向对象数据库更普遍的原因是什么？
如果面向对象编程范式如此普及，我们不应该看到很多OODBMS吗？它们难道不比RDBMS+OR/M表现更好吗？
9个回答
37
关系型数据库管理系统(RDBMS)之所以保持着流行，有一个原因是其作为一项成熟技术被广泛理解，并且拥有多个供应商支持的标准语言(SQL)，同时还有一些像ODBC和JDBC这样的优秀接口，可以非常好地与不同语言连接。稳定的API是保持技术主导地位的一个强有力的因素。
相比之下，面向对象数据库管理系统(OODBMS)没有明确的模型，也没有标准语言或标准的API。甚至连领先的供应商实现都没有形成事实上的标准。
可能性来说，OODBMS概念比RDBMS+ORM表现更出色。但这完全取决于具体实现。但同时也要认识到，OODBMS不能解决RDBMS擅长解决的一组问题。如果你需要数据管理解决方案执行引用完整性和关系头，则某些数据管理任务将更容易完成。而这些特征在OODBMS模型中是缺失的（至少目前是如此）。
博客上存在大量声音认为关系型数据库已经过时了，但实际上RDBMS仍然是绝大多数数据管理任务的最佳通用解决方案。
- Bill Karwin
1
Objectivity/DB自20世纪90年代初就具有引用完整性。 - djhallx
21
我看到的最大问题是缺乏标准化。在关系数据库管理系统（RDBMS）领域，只要你懂SQL，就可以使用任何随机数据库并取得相当大的进展。它们基本上都实现了它，只有一些微小的差异。我不知道任何一个现有的RDBMS不做SQL的：你几乎可以互换使用“RDBMS”和“SQL”。
对于面向对象数据库管理系统（OODBMS）而言，最接近的可能是OQL，但它已经彻底失败了。没有一个数据库实现了很多它的内容。我几年前使用过一个非常好的商业OODBMS，但是（截至2007年左右，它已经是主要版本8或9），它甚至不支持按名称查询对象。手册简单地说，这部分OQL他们还没有开始处理。（我不确定，但你可能能够降级到本机调用来完成这个操作。）
我最近看到的大多数对象数据库都具有本地语言接口，而不是像OQL这样的查询语言。例如，我使用的系统仅支持Perl和VB（仅限！）。将受众限制为仅有几种语言（或强制他们编写包装器，就像我们所做的那样）并不是赢得朋友的方式。
由于这个原因，没有竞争，因此也没有易于备份的计划。如果你将数据放入MS-SQL中，而Microsoft停止支持它，你可能可以将数据转储到Postgres中并迁移查询，而不会遇到太多问题。（如果你有很多查询，这可能是很多工作，但我不怀疑你能做到。这很麻烦，但并不具有技术挑战性。）或Oracle、MySQL或许多其他商业和免费的数据库。
没有一个OODBMS可以做到这一点：如果你正在使用的OODBMS出现问题，或者它朝着你不需要的方向发展，或者你发现它缺少你需要的关键功能，你不能只是将数据转移到竞争对手的OODBMS并移植查询。相反，你需要改变核心库并进行大规模的架构更改。因此，从实际角度考虑，你只能选择一个真正信任的商业OODBMS（你能列出一个吗？）或一个开源OODBMS，在出现问题时信任你的团队维护。
对于面向对象数据库管理系统（OODBMS）而言，最接近的可能是OQL，但它已经彻底失败了。没有一个数据库实现了很多它的内容。我几年前使用过一个非常好的商业OODBMS，但是（截至2007年左右，它已经是主要版本8或9），它甚至不支持按名称查询对象。手册简单地说，这部分OQL他们还没有开始处理。（我不确定，但你可能能够降级到本机调用来完成这个操作。）
我最近看到的大多数对象数据库都具有本地语言接口，而不是像OQL这样的查询语言。例如，我使用的系统仅支持Perl和VB（仅限！）。将受众限制为仅有几种语言（或强制他们编写包装器，就像我们所做的那样）并不是赢得朋友的方式。
由于这个原因，没有竞争，因此也没有易于备份的计划。如果你将数据放入MS-SQL中，而Microsoft停止支持它，你可能可以将数据转储到Postgres中并迁移查询，而不会遇到太多问题。（如果你有很多查询，这可能是很多工作，但我不怀疑你能做到。这很麻烦，但并不具有技术挑战性。）或Oracle、MySQL或许多其他商业和免费的数据库。
没有一个OODBMS可以做到这一点：如果你正在使用的OODBMS出现问题，或者它朝着你不需要的方向发展，或者你发现它缺少你需要的关键功能，你不能只是将数据转移到竞争对手的OODBMS并移植查询。相反，你需要改变核心库并进行大规模的架构更改。因此，从实际角度考虑，你只能选择一个真正信任的商业OODBMS（你能列出一个吗？）或一个开源OODBMS，在出现问题时信任你的团队维护。
如果这听起来像FUD，抱歉，我没有这个意图。但是我曾经经历过这种情况，从项目管理的角度来看，即使编程环境可能非常好，我也会犹豫再次尝试。另一种思考方式是：看看今天函数式编程有多么流行，尽管这是一个好主意。OODBMS就像这样，但更糟，因为它不仅涉及你的代码，还包括你的代码和数据。我很乐意今天在Erlang中启动一个重大项目，但我仍然会犹豫使用OODBMS。
OODBMS供应商：要改变这种情况，你需要让用户容易离开你去找竞争对手。你可以挖掘OQL并实际实现它，或者像ODBC一样在API级别上实现它，或者其他方式。甚至一个标准的转储格式（使用JSON？），以及用于将多个OODBMS导入/导出到该格式的工具，都是一个很好的开始。
- Ken
16
数据通常比程序更重要且具有更长的生命周期。因此，即使您今天开始进行全新的开发，也必须考虑整体情况。有更多的工具、流程和经验丰富的人在使用关系型数据库管理系统。请不要仅局限于程序方面，还需考虑容量规划、数据挖掘、报告、ETL、与其他数据源的集成等方面。如果您的公司收购了另一家公司并将所有关系型数据带入您的程序中，那么该怎么办？RDBMS及其相关工具已经深入人心，被证明非常强大，我认为使用其他任何东西都没有战略意义。也许在某些小型细分市场中可能会使用其他技术，但总体而言，不建议这样做。
- softveda
3
7“数据通常比程序寿命更长，且更为重要。” - 确实如此。中间层会来来去去，但数据永存不灭。 - duffymo
1面向对象数据库管理系统（OODBMS）与关系型数据库管理系统（RDBMS）一样，不意味着被绑定到特定的编程语言，就像 RDBMS 也不会被绑定到实现特定的存储过程一样。 - L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
2理论上你是正确的，但在实践中，只有少数被广泛支持的关系数据库管理系统(RDBMS)实现以及拥有大量工具、知识库和经验丰富的人员。我的公司刚刚经历了一次企业合并，我们将数据从对方公司的数据库导入到我们的数据库中（需要大量转换、数据整理和清洗）。由于双方公司都使用Oracle，这使得事情变得更容易，而如果对方公司使用一些鲜为人知的数据库，情况肯定会更加复杂。 - softveda
6
对象数据库在解决几何表示问题（例如CAD系统）等方面有非常好的应用领域，其中对象图可以非常深。在大多数关系型系统中，当涉及到7个或更多表时，JOIN性能会迅速下降，因此在CAD中具有深度自引用结构的情况下，对象数据库的性能更佳。
但是像金融数据这样的重要应用程序适合使用关系型表示。关系模型具有坚实的数学基础，SQL是一种成功和流行的语言。对于银行、经纪公司和保险公司等金融机构来说，没有太多动力从RDBMS转换。
- duffymo
4
对于一些简单的例子，面向对象数据库和关系型数据库可能会有很大的区别。特别是当你处理的数据量足够小，可以轻松地将所有数据一次性读入内存并一次性写出时。但最终，面向对象数据库需要以非常类似关系型数据库的格式保存数据 - 它们并没有那么不同。
考虑一个任意的对象图形，它可能在应用程序中使用。每个对象都可以被多个其他对象引用。当您保存对象图形时，您不想重复保存每次引用它们的对象。首先，如果您有任何类型的循环或自引用，您的保存对象方法将进入无限循环。但是在一般情况下，这是浪费空间的。相反，任何重要的数据存储需要为要存储的每个对象声明唯一标识符（键，通常是RDBMS术语中的代理键）。引用它的每个其他对象都保存对象类型和键，而不是重复保存整个对象。因此，在我们的非关系型对象存储中，我们重新创建了外键。
接下来，假设我们要存储与另一个对象（B）相关联的对象列表（A1、A2、A3...）。我们已经确定将存储键而不是两次保存对象本身。但是，您是将A1、A2、A3...对象的键存储在对象B上，还是将对象B的键存储在A上？如果您以第一种方式存储它们，并且您拥有所有所需的A，您可以快速获取相关的B。第二种方法相反。但是无论哪种方式都是单向交易。如果要查询所存储内容的反向并且对象存储为XML或JSON，则需要通过大量无关信息进行低效的解析以查找每个文件中的键。将它们存储在每个字段分开的格式中是否更好，就像表格中的列一样？
在多对多关系或需要在两个方向上查找大量对象的情况下，此策略变得非常低效。唯一高效的解决方案是制作一个帮助器对象来存储关系，每个关系都有一个文件，该文件由A的键和B的键组成，以便可以快速查找它们。我们刚刚重新发明了交叉引用表。
具有列、唯一标识符（键）、交叉引用表...这些是以有效方式存储对象以便能够高效检索的基本需求。嗯...这听起来像什么熟悉的东西？关系型数据库正是提供这种功能。此外，多个供应商已经竞争数十年，提供最快的数据存储和检索，以及备份、复制、集群、查询等最佳工具。这让新技术要与之竞争变得困难。最终，我认为关系型数据库基本上是高效对象存储问题的一个非常好的解决方案。
这就是为什么像Hibernate这样的东西存在 - 将面向对象的接口放在高效的关系型数据库存储系统上。您会发现其他类型的存储在不同的问题领域中表现出色：
考虑一个任意的对象图形，它可能在应用程序中使用。每个对象都可以被多个其他对象引用。当您保存对象图形时，您不想重复保存每次引用它们的对象。首先，如果您有任何类型的循环或自引用，您的保存对象方法将进入无限循环。但是在一般情况下，这是浪费空间的。相反，任何重要的数据存储需要为要存储的每个对象声明唯一标识符（键，通常是RDBMS术语中的代理键）。引用它的每个其他对象都保存对象类型和键，而不是重复保存整个对象。因此，在我们的非关系型对象存储中，我们重新创建了外键。
接下来，假设我们要存储与另一个对象（B）相关联的对象列表（A1、A2、A3...）。我们已经确定将存储键而不是两次保存对象本身。但是，您是将A1、A2、A3...对象的键存储在对象B上，还是将对象B的键存储在A上？如果您以第一种方式存储它们，并且您拥有所有所需的A，您可以快速获取相关的B。第二种方法相反。但是无论哪种方式都是单向交易。如果要查询所存储内容的反向并且对象存储为XML或JSON，则需要通过大量无关信息进行低效的解析以查找每个文件中的键。将它们存储在每个字段分开的格式中是否更好，就像表格中的列一样？
在多对多关系或需要在两个方向上查找大量对象的情况下，此策略变得非常低效。唯一高效的解决方案是制作一个帮助器对象来存储关系，每个关系都有一个文件，该文件由A的键和B的键组成，以便可以快速查找它们。我们刚刚重新发明了交叉引用表。
具有列、唯一标识符（键）、交叉引用表...这些是以有效方式存储对象以便能够高效检索的基本需求。嗯...这听起来像什么熟悉的东西？关系型数据库正是提供这种功能。此外，多个供应商已经竞争数十年，提供最快的数据存储和检索，以及备份、复制、集群、查询等最佳工具。这让新技术要与之竞争变得困难。最终，我认为关系型数据库基本上是高效对象存储问题的一个非常好的解决方案。
这就是为什么像Hibernate这样的东西存在 - 将面向对象的接口放在高效的关系型数据库存储系统上。您会发现其他类型的存储在不同的问题领域中表现出色：
- 对于任何一种无结构文档存储（博客、源代码控制或任何不能映射到行和列的东西），各种NoSQL数据库都是理想的选择。
- 保持易于查询且有意义的更改历史记录（例如源代码控制中的diff）在关系型数据库中并不美观。Datomic可能在这方面开辟了新的领域。
- 如果您的对象图形简单或小，那么使用数据库的开销可能是不必要的。
面向对象数据库（OODBs）不能比关系型数据库（RDBs）表现更好，因为它们并没有根本区别。
关系型数据库会一直存在，因为以节省空间、节省保存和检索时间、容错性以及一定数据完整性保证的方式保存大量对象图形是关系型数据库最初设计解决的问题。这就是为什么JPA和Hibernate也会一直存在 - 因为它们弥合了对象模型和关系模型之间的差距。对象模型用于内存中的操作方便，而关系模型用于持久化。
- GlenPeterson
2
1不，这个答案完全是错误的。OODB存储对象页面，并且可以在同一页中存储不同类型的对象。这使它们更加高效，因为它们可以将相关信息一起存储。有关实现的详细说明，请参阅詹姆斯·福斯特（James Foster）的视频，从https://www.youtube.com/watch?v=U0z5TddqyQI&t=13s开始。 - Stephan Eggermont
这篇文章已经过时了。"OODBs不能比RDBs表现更好，因为它们在根本上并没有什么不同。" 这是根本错误的。对于导航复杂的对象图，一个对象/图形数据库每次都会击败关系型数据库。JPA和Hibernate表现良好，因为人们只能访问关系型数据库，所以他们尽力存储他们的对象。www.objectivity.com - djhallx
3
总之，互操作性（周五晚上的一个大词 <G>）是关键。
大多数企业必须使用运行在RDBMS上的旧系统。即使他们使用OODBMS，他们仍需要访问RDBMS以执行某些功能。只维护一种数据访问方式比两种更容易。
当你拥有像Oracle和SQL Server这样的大型OODBMS名称，并在各种环境中证明了性能，那么你将看到更多的项目使用它们。
- Brad Bruce
0
主要问题是索引！
对于标量值进行索引真的很好……只需排序即可。
对于具有许多属性、方法、部件、组件等的值，没有通用规则……
因此，面向对象数据库管理系统像恐龙一样消失了！
但是关系型数据库管理系统供应商集成了一些功能，可以在数据库中存储对象，例如 XML（有时需要进行研究和开发以找到特定实际使用对象的索引方式，但这非常困难……），还支持存储任何类型的对象（无法对其进行索引……）通常在 Java（Oracle）或 .net（SQL Server）中。
- SQLpro
1
Objectivity/DB已经拥有完整的高速索引集合近30年了。我们还可以在另一个对象内部使用可扩展的集合属性。OODBMS肯定是一个利基行业。它们存在于您的手机塔、每个行业的CAD/CAM/CAE商店以及所有军事部门中。它们经常用作大规模数据和传感器融合系统的数据存储库，因为它们可以处理复杂的数据模型，而关系数据库无法跟上。 - djhallx
0
我认为这是一个
不破不立。
关系型数据库非常根深蒂固。
- ChaosPandion
2
4“如果它没坏，就不要去改变它”这种说法太蠢了……为什么要让事情变得更好，或者让软件开发更快是一件坏事？当我更换旧电脑时，它并没有坏，只是变得很慢！！！作为一名开发者，努力寻求更好、更高效的解决方案是我的目标。 - billy
1@billy - 等你有机会工作在一些极其大的遗留系统上再来说这话吧…我认为你会明白为什么通常要避免不必要的改变 ;) - michjnich
-1
最直接的回答为什么关系数据库比对象数据库更常见的问题是，大多数问题可以使用关系数据库解决。绝大多数人有一套工具，在他们遇到的几乎所有问题中都可以使用它来解决。对于程序员来说也是如此。许多程序员只需要关系数据库，因此关系数据库市场就在那里为他们服务。
然而，如果你为CAD/CAM/CAE行业开发软件，或者开发链路分析应用程序以支持调查，或者构建复杂的数据融合系统，你可能会在你的工具箱中拥有一个对象/图形数据库，因为它们在这些领域的性能比关系数据库好得多。
免责声明：我在Objectivity, Inc.工作，我们生产、销售和营销高度可扩展的分布式对象/图形数据库。
然而，如果你为CAD/CAM/CAE行业开发软件，或者开发链路分析应用程序以支持调查，或者构建复杂的数据融合系统，你可能会在你的工具箱中拥有一个对象/图形数据库，因为它们在这些领域的性能比关系数据库好得多。
免责声明：我在Objectivity, Inc.工作，我们生产、销售和营销高度可扩展的分布式对象/图形数据库。
- djhallx
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接