Web 开发 - 对象数据库与关系数据库答案

【问题标题】：Web Development - Object db vs Relational dbWeb 开发 - 对象数据库与关系数据库
【发布时间】：2011-07-18 12:07:56
【问题描述】：

在涉及大量 CRUD 的常规 Web 开发中使用对象数据库或关系数据库的优缺点是什么？

更新：我重新开放赏金奖励是为了给 Neville。

【问题讨论】：

完全同意这里的专业人士。行业标准是使用 ORM + RDBMS。
请关注语义技术。我个人认为语义数据存储优于关系数据存储。 AFA作为OODBMS而言，技术或算法还不够成熟，无法与RDBMS相提并论。
行业标准对于常规 Web 开发来说是错误的。 OODBMS 已经足够成熟：看看 JP Morgan 使用 Gemstone 的时间。
Rob Conery 有一系列 (blog.wekeroad.com/category/nosql) 的帖子吹捧 OODBMS。这里的这个 (blog.wekeroad.com/2010/02/05/reporting-in-nosql) 讨论了 RDBMS 在 OODBMS 世界中的意义所在。这是一篇关于同时使用两者的帖子：blog.wekeroad.com/2010/05/19/no-sql-in-the-wild

标签： database relational-database object-oriented-database

【解决方案1】：

这几乎解释了利弊：

http://en.wikipedia.org/wiki/Object_database

【讨论】：

那篇文章很糟糕。诸如“OODBMS 在某些情况下可能比关系 DBMS 更快，因为数据不是存储在关系行和列中而是作为对象存储”之类的评论表明完全不了解关系模型的含义。如果将“关系”替换为“SQL”，那将是有意义的。此外，结束 argument 在百科全书中没有位置。
@Marcelo：“在某些情况下可能更快并且（我的补充）在更多情况下可能会更慢”。明天内华达州可能会下雨，也可能不会:)
@ypercube：困扰我的不是“可能更快”。对我来说是“关系行和列”。对关系模型稍有了解的人都知道，它与行和列完全没有关系，SQL 表的行和列是对理论关系、元组和属性的拙劣模仿。

【解决方案2】：

OODBMS 的概念已经被打破，过去几十年出现的各种商业和免费产品几乎没有在市场上发挥作用。

就您可以对数据提出的问题类型而言，关系模型比对象模型更强大。不幸的是，SQL 放弃了关系模型所具备的大部分表达能力，但即使在这种稀释的形式下，用 SQL 表达查询仍然比在典型的 OO 数据库（无论是 ORM 还是 OODBMS）中更容易。

OODBMS 中的查询主要由导航操作符驱动，这意味着如果您的销售数据库中有销售人员拥有他们的销售额，那么查询给定 SKU 的月销售额不仅可能会非常缓慢，而且非常尴尬表达。还要考虑一种授予员工访问建筑物的安全模型。哪种表达方式是正确的？员工应该持有一组他们可以访问的建筑物，还是应该持有一组可以访问它们的员工？更重要的是，为什么任何一个类都必须在其设计中包含另一个类的集合？而且，无论你选择哪一个，你会如何询问哪对员工有不止一栋可以共用的建筑物？没有直接的导航模式可以回答这样的问题。明智的解决方案——“访问”对象——本质上是对适当规范化的关系模式的回归，它需要某种从关系代数中大量借用的查询语言，以便在没有大量过度的情况下回答问题。有线数据传输。

还要考虑被吹捧为 OODBMS 的另一个主要优势：方法，尤其是虚拟方法的继承。对于不同类型的运动员，运动诊所可能有不同的受伤风险指标。在 ORM 世界中，这将自动表示为类层次结构，Athlete 位于根部，虚拟方法 int InjuryRiskScore() 由每个派生类实现。问题是这种方法总是在客户端实现，而不是在后端，所以如果你想在你的诊所找到所有运动中风险最高的 10 名运动员，唯一的方法是获取所有运动员。连线并通过客户端优先级队列传递它们。我也不了解 OODBMS 世界，但我认为会出现同样的问题，因为存储引擎通常只存储足够的数据来用客户端的编程语言重新水化对象。在关系模型或 SQL 中，您可以将受伤风险评分表示为一个视图，这可能只是每个运动员类型视图的联合。然后，您只需提出问题。或者您可以提出更复杂的问题，例如“自上个月的检查以来，谁的受伤风险增加最大？”甚至，“哪个风险评分已被证明是去年受伤的最佳预测指标？”。最重要的是，这些问题都可以在 DBMS 内部得到解答，而不仅仅是问题和答案通过网络传输。

关系模型允许 DBMS 以基于谓词逻辑的高度提炼的方式表达知识，这允许您存储在其中的事实的各个维度被连接、投影、过滤、分组、汇总和以其他方式重新排列在一个完全临时的方式。它允许您以最初设计系统时未预料到的方式轻松地处理数据。因此，关系模型允许我们所知道的最纯粹的知识表达。简而言之，关系模型拥有纯粹的事实——不多不少（当然也不是对象或其代理）。

从历史上看，关系模型的出现是为了应对当时现有网络和分层 DBMS 的灾难性状态，并且在很大程度上（并且正确地）取代了它们，除了一小部分应用领域（以及甚至这些可能在很大程度上仍然存在，因为 SQL 未能发挥 RM 的能力）。具有讽刺意味的是，大部分行业现在基本上都在向往网络理论数据库的“过去的美好时光”，而这基本上是 OODBMS 和当前的 NoSQL 数据库正在回归的东西。这些努力正确地批评了 SQL 未能满足当今的需求，但不幸的是，他们假设（错误地，并且可能出于纯粹的无知）SQL 是关系模型的高保真表达。因此，他们甚至忽略了关系模型本身，它几乎没有导致这么多人远离 SQL，通常转向 OODBMS 的限制。

【讨论】：

很明显，您从未使用过 Gemstone。你的论点没有任何意义
1 Gemstone的查询模型比关系型数据库强大很多
2 您的查询示例在关系数据库中比在 Gemstone 中表达要慢得多且难以表达，尤其是当您尝试进行多维分析（数据仓库）时
3 关系模型无法扩展。它使用了错误的抽象（Set 而不是 Ordered Set）。
@Stephan: 1) 你知道 SQL 和关系模型/代数之间的区别吗？ 2）你需要更具体；我引用的问题在 SQL 中很容易表达。 3）我不理解集合使事物的可伸缩性不如有序集合的说法；强加的排序使优化者更难，而不是更容易。我在 Microsoft 为分布式系统开发了一种查询语言，该语言在全扫描即席查询上的处理速度约为 1 TB/分钟；没有订购限制对于实现这一目标至关重要。 4）关系模型对类型没有限制； SQL 可以。

【解决方案3】：

我认为一切都取决于您的问题的具体情况。（我知道，我在这里真的很危险。）

我们所知道的是，您想使用数据库进行 Web 开发，并且您将对数据进行大量操作。

要问自己的一个相关问题是，数据库与您操作的对象紧密集成有多重要？越需要，面向对象的数据库就越推荐自己。

另一方面，如果您的数据很容易适用于关系模型，那么关系数据库可能会更好。

考虑一下您需要执行的操作。您是否需要分析具有不同属性的各种项目？您需要多少费用才能让您的数据库适应未来的需求？

我应该补充一点，如果您的数据库可能相当小，那么性能将不是主要问题。但是，如果性能实际上是一个问题，那么除了 OO 与关系数据库之外，您还有很多事情要担心。（仅从关系数据库世界中选择一个示例，您应该使用哪种规范化形式？这是一个非常重要且复杂的问题。您是在维护操作系统还是数据仓库？您是否提前知道某些查询是是最重要的，还是可以忽略不计的？&c.)

除了数据库性能和与您的对象模型集成的问题之外，还有其他现实问题需要问。你有磁盘空间/服务器/带宽限制吗？您是否会只向网络用户提供少量操作，或者您甚至不认识的人可能会创建自己的查询/编辑？

对于其他更重要的现实问题，您将与谁合作？他们已经知道（或喜欢）什么？如果您还没有领域知识，也许您有个人好奇心将您推向一个方向？如果您开始进行个人项目，那么遵循自己的喜好比在开始之前担心性能更好地指导成功。

如果你能回答这些和类似的问题，即使答案是“我不知道”，你也能更好地指导如何继续。

【讨论】：

【解决方案4】：

根据 Marcelo 的深入和深思熟虑的回应，我想说的是，根据你对“常规 Web 开发”问题的措辞，我的即兴回应是说你很难找到足够多的专业人士来证明使用对象数据库而不是传统的关系数据库是合理的，因为简单的事实是更多的资源/开发人员/教程/等更熟悉传统的关系模型，以及如何利用它来实现“常规 Web 开发”。

也就是说，我认为使用某些现代 ORM，您可以获得两全其美的优势，因为您的基础数据存储在易于理解的 RDBMS（可能是稳定的、受支持的等）中，但您仍然可以抽象出一些（可以说）更适合开发 CRUD 应用程序的对象建模功能。

我承认我并不精通现代 OODBMS 的当前功能，但除非您所在的领域完全适合实现您的领域的完美对象表示（并且您拥有对象建模天赋）以利用），那么我会坚持使用 RDBMS 作为您的持久存储。

希望有帮助！

【讨论】：

【解决方案5】：

关系数据库：

优点：

成熟的技术 - 很多工具、开发人员、资源
广泛的开源和商业产品
已知可以扩展到非常大站点和非常高的吞吐量
以逻辑和“可编程”的方式表达许多问题域
相当标准的语言 (SQL)

缺点：

与 OO 概念的阻抗不匹配 - 在数据库中建模“继承”是不自然的
分层结构通常需要对语言进行特定于供应商的扩展
非关系型数据（例如文档）并非天作之合
一旦定义了架构，业务域中的更改就很难实施

OOBDMS

优点：

更适合 OO 概念
理论上，开发人员只需要使用一种语言工作 - 持久性细节被抽象掉了。这应该会提高生产力

缺点：

可用的工具/资源/开发人员明显减少。
没有被广泛接受的标准
“黑匣子”持久化方法会使性能调优变得困难
持久性细节经常泄漏到 OO 设计中（参见 Marcelo 的示例）

【讨论】：

在 23 小时内提供赏金 - 这些天很忙 :)
OODBMS 的另一个专业人士：可以处理大量数据（如果您能负担得起价格）
顺便说一句：再加上 ORM 框架（即 Hibernate），RDBMS 系统可以在对开发人员更自然的模型中使用，但代价是性能和复杂性（它们封装了数据库访问，但你必须学习如何正确使用它们）。如今，ORM 工具已经非常成熟，为 RDBMS 引入的一些问题提供了很好的解决方案。
“以逻辑和“可编程”的方式表达许多问题域？

【解决方案6】：

我可以回答您关于我熟悉的一个对象数据库的问题：ZODB。

ZODB 允许您几乎完全透明地保存数据模型。它的用法相当于：

 # 'Persistent' allows us to save things transparently
 class Car(Persistent):
   def set_wheels(number)
      self.wheels = number

 # 'database' is a ZODB database
 database.car = Car()
 database.car.set_wheels(3)

您必须花很长时间才能找到 RDMBS 的那种可读性。在 Web 应用程序中使用 ZODB 有很大的好处。

正如 Marcello 所述，最大的缺点是缺乏强大的查询功能。这部分是上述成语方便的副作用。以下是完全OK的，一切都会被持久化到数据库中：

 database.car.colour = "yellow"
 database.car.owner = "Trotter"
 database.car.neighbour = Car()

但是，这种灵活性使得跨不同模型优化复杂查询变得困难。除非您滚动自己的索引，否则仅列出所有有邻居的黄色汽车将需要 O(n) 时间。

所以，这取决于您所说的“常规 Web 开发”是什么意思。许多网站实际上并不需要复杂的多维查询，线性时间的搜索完全没有问题。在这些情况下，我认为使用 RDBMS 会使您的代码过于复杂。我已经编写了许多只使用对象数据库的 CMS 类型的应用程序。很多 CRUD 并没有特别涉及它。 ZODB 非常成熟，可扩展性和缓存都非常好。

但是，如果您正在编写一个需要按照 Google Analytics（分析）进行复杂业务报告的网络应用程序，或者是某种具有数 TB 数据的仓库库存管理系统，那么您肯定会想要一个关系型数据库。

总而言之，对象数据库可以以复杂的查询性能为代价为您提供可读性和可维护性。当然，可读性是一个见仁见智的问题，您不能忽视这样一个事实，即了解 SQL 的开发人员比各种对象数据库方言要多得多。

【讨论】：

在像 Gemstone 这样的普通 OODBMS 中，查询比在 RDBMS 中强大得多

【解决方案7】：

在常规的 Web 开发中，我使用 Seaside on Gemstone。对于大多数应用程序，这意味着我编写零数据库连接代码。它执行、扩展、开发速度大约快五倍。

我将再次使用关系数据库进行 Web 开发的唯一一次是当我必须连接到现有数据库时。

优点：

更少的代码，更快的开发；
更好的可扩展性；
可以处理更复杂的模型；
更好的项目敏捷性；
我提到过灵活性吗？
可以处理类模型的变化，不仅是数据，还有代码；

缺点：

您可能必须自己培训开发人员；
您想要的（宝石）对于大型系统来说要花很多钱

【讨论】：

【解决方案8】：

关系数据库

SQL 和标准
易于建模
只能使用标准和供应商类型
参照完整性（数学上可靠的relational set theory）
大量工具和数据库实现
数据与程序分开
存储管理和高端基础架构支持
在内部完成事务和并发管理
关系模型是基于值的，即行由主键标识

缺点

没有自定义类型
没有可扩展的数据类型
阻抗不匹配
无法表达嵌套关系
不能将复杂实体作为一个单元使用
需要在数据模型级别定义键和各种类型的关系
根据需要编写版本控制程序和事务

对象数据库

高性能
更快，因为不需要连接
固有的版本控制机制
操作的导航界面（如图形遍历）
对象查询语言以声明方式检索对象
复杂的数据类型
对象身份，即。 equals() 对象身份独立于值和更新
促进对象共享
类和层次结构（继承和封装）
支持关系
与 ODL 等持久性语言集成
支持原子性
支持嵌套关系
语义建模

缺点

没有 RDB 的数学基础（参考 Codd）
面向对象的缺点
复杂结构难以持久化，某些数据必须是瞬态的

对象关系数据库（您可能见过 UDT！）

支持复杂的数据类型，如集合、多集等
面向对象的数据建模
扩展的 SQL 和丰富的类型
支持 UDT 继承
强大的查询语言

不同的应用程序可能需要不同的方法（OO、关系 DB 或 OODB）

参考文献

The advantage of using relational databases for large corpora

Relational Database Relational Database

OODMS manifesto

ODMG

Benefits of a relational database

The Object-Oriented Database System Manifesto

Object Oriented Database Systems

Object Relational Databases in DBMS

Completeness Criteria for Object-Relational Database Systems

比较

http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

http://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems

http://en.wikipedia.org/wiki/Comparison_of_object-relational_database_management_systems

【讨论】：

没有数学基础是有缺陷的论证。数学不仅仅是集合论。图灵和迪杰斯特拉都是数学家。
文章“为大型语料库使用关系数据库的优势”无法与 OODB 相比。如果我没看错的话，使用 OODB 会更容易解决这个问题
“关系数据库的好处”列举了四个好处，实际上 OODB 在所有这些好处上的得分明显更高
是的，我只想指出两者的不同用例。对于 OODB，没有像 RDB 那样的明确数学理论的支持。关于这篇文章，通常语料库是在图形数据库中定义的（用于建模语义关系），但也可以使用 RDB。 “关系数据库的好处”只是一个简单的参考
与程序分离的数据应该被列为 RDBMS 的一个重要缺点。这是数据质量低的原因。它使参照完整性成为一个实际上无用的概念。