Web开发 - 面向对象数据库 vs 关系型数据库

Question

Web开发 - 面向对象数据库 vs 关系型数据库

databaserelational-databaseobject-oriented-database

14

使用面向对象数据库或关系型数据库进行常规Web开发（包括大量的CRUD）的优缺点是什么？

更新：我重新打开奖励以将其授予Neville。

- ebb

完全同意这里的专家意见。行业标准是使用ORM + RDBMS。 - Stephen Chung

请关注语义技术。我个人认为，语义数据存储优于关系型数据存储。就面向对象数据库管理系统而言，该技术或算法还不够成熟，无法与关系型数据库管理系统相比较。 - uncaught_exceptions

行业标准对于常规的网页开发是错误的。面向对象数据库管理系统已经足够成熟：看看摩根大通使用Gemstone已经有多久了。 - Stephan Eggermont

Rob Conery有一系列博客文章(http://blog.wekeroad.com/category/nosql)推崇OODBMS。这篇(http://blog.wekeroad.com/2010/02/05/reporting-in-nosql)讨论关于在OODBMS世界里，RDBMSs何时是有意义的。这里有一篇关于同时使用两者的文章：http://blog.wekeroad.com/2010/05/19/no-sql-in-the-wild - Talljoe

8个回答

17

关系型数据库:

优点:

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

缺点:

与面向对象概念的阻抗不匹配-在数据库中建模"继承"不是自然的
分层结构通常需要供应商特定的语言扩展
非关系数据(如文档)并不是一个自然的选择
一旦定义了模式，实施业务域的更改可能很难

面向对象数据库管理系统(OOBDMS)

优点:

更符合面向对象的概念
理论上，开发人员只需使用一种语言-持久性细节被抽象化。这应该提高生产力。

缺点:

可用的工具/资源/开发人员数量显著较少。
没有广泛接受的标准
持久性细节往往泄漏到面向对象的设计中(参见马塞洛的示例)
"黑盒"方法使性能调整困难

- Neville Kuyt

23小时后发放悬赏 - 最近有点忙 :) - ebb

另一个 OODBMS 的优势：可以处理更大量的数据（如果你能承担得起价格）。 - Stephan Eggermont

顺便说一句：与ORM框架（如Hibernate）结合使用，RDBMS系统可以以更符合开发人员自然思维的模式使用，但代价是性能和复杂性（它们封装了数据库访问，但您必须学会正确使用它们）。 ORM工具现在非常成熟，并为RDBMS引入的某些问题提供了良好的解决方案。 - NightDweller

以逻辑和“可编程”的方式表达许多问题领域。 - Stephan Eggermont

4

我可以就我熟知的一个对象数据库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所概述的，缺乏强大的查询功能是一个明显的缺点。这部分是上述习语的便利的副作用。以下代码完全可行，并且所有内容都将持久化到数据库中：

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

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

因此，这取决于您所说的“常规Web开发”的含义。许多网站实际上不需要复杂的多维查询，并且按线性时间进行搜索根本没有问题。在这些情况下，使用关系数据库管理系统会在我看来过于复杂化您的代码。我使用纯对象数据库编写了许多CMS类型的应用程序。大量的CRUD并不特别涉及它；ZODB非常成熟，并且缓存和扩展性也相当不错。

但是，如果您正在编写需要执行类似于Google Analytics的复杂业务报告或某种具有数千兆字节数据的仓库库存管理系统的Web应用程序，则几乎肯定需要关系数据库管理系统。

总之，对象数据库可以为您提供可读性和可维护性，代价是复杂查询性能。当然，可读性是一个主观问题，而且不能忽视很多更多的开发人员知道SQL而不是各种对象数据库方言的事实。

- seb

在普通的面向对象数据库管理系统（OODBMS）中，例如Gemstone，查询功能比关系型数据库管理系统（RDBMS）更强大。 - Stephan Eggermont

3

关系型数据库

SQL和标准化
易于建模
可以使用标准和供应商类型
参照完整性（在数学上是可靠的关系集合理论）
有很多工具和数据库实现
数据与程序分离
存储管理和高端基础设施支持
事务和并发管理由内部完成
关系模型是基于值的，即行通过主键进行标识

缺点

没有自定义类型
没有可扩展的数据类型
阻抗不匹配
无法表达嵌套关系
无法将复杂实体用作单个单位
需要在数据模型级别定义键和各种类型的关系
如果需要，编写版本控制、事务等过程

对象数据库

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

缺点

没有像RDB（参考Codd）那样的数学基础
面向对象的缺点
对于复杂结构的持久性很难，一些数据必须是瞬态的

对象-关系数据库（您可能已经看到了UDT！）

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

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

参考文献

比较

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

- zudokod

没有数学基础是一个有缺陷的论点。数学不仅仅只有集合论。图灵和迪科斯彻都是数学家。 - Stephan Eggermont

文章“在处理大型语料库时使用关系型数据库的优势”并没有与面向对象数据库进行比较。如果我理解正确，这个问题用面向对象数据库会更容易解决。 - Stephan Eggermont

“关系型数据库的好处”列举了四个优点，但实际上，在所有这些优点方面，面向对象数据库（OODB）都表现得更好。 - Stephan Eggermont

是的，我只想指出它们的不同用例。对于OODB，没有像RDB那样支持明确数学理论的后盾。关于这篇文章，通常语料库在图形数据库中定义（用于建模语义关系），但也可以使用RDB。 “关系型数据库的好处”只是一个简单的参考。 - zudokod

1

将数据与程序分开应列为关系型数据库的一个重要缺点。这是低数据质量的主要原因。它使得参照完整性成为一个几乎无用的概念。 - Stephan Eggermont

3

在常规的Web开发中，我使用Gemstone上的Seaside。对于大多数应用程序来说，这意味着我不需要编写任何数据库连接代码。它执行得快，可扩展性好，开发速度约为五倍。

唯一会再次使用关系型数据库进行Web开发的情况是必须连接到现有数据库时。

优点：

- 代码量少，开发速度更快； - 可扩展性更好； - 可处理更复杂的模型； - 项目敏捷性更高； - 我提到了灵活性吗； - 可以处理类模型的变化，不仅仅是数据还包括代码；

缺点：

- 你可能需要自己培训开发人员； - 你想要的那个（gemstone）对于大型系统来说需要花费相当多的钱。

- Stephan Eggermont

1

我认为一切都取决于你的问题的具体情况。（我知道这很冒险。）

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

其中一个相关的问题是，DB与你操作的对象紧密集成有多重要？如果非常重要，那么面向对象的DB就更推荐了。

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

考虑一下你需要做的操作。你是否需要分析各种具有不同属性的项目？你需要多少来未雨绸缪你的数据库？

我应该补充说，如果你的数据库可能相当小，性能不会是一个主要问题。但是，如果性能确实是一个问题，除了面向对象与关系型数据库之外，你还有很多事情需要担心。（只是从关系型数据库世界中挑选一个例子，你应该使用什么规范化形式？这是一个非常重要且复杂的问题。你是在维护操作系统还是数据仓库？你是否提前知道某些查询非常重要或者可以忽略？等等。）

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

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

如果您可以回答这些类似的问题，即使答案是“我不知道”，您也将能够获得更好的指导方向。

- JXG

1

与马塞洛深入思考并深思熟虑的回答不同，我认为基于你的问题“常规网站开发”，我的即兴回答是您很难找到足够的专业人士来证明使用对象数据库优于传统关系型数据库，因为更多的资源/开发人员/教程等都熟悉传统的关系模型以及如何利用它实现“常规网站开发”。

话虽如此，我认为一些现代ORM可以获得最佳的两个世界，即底层数据存储在一个众所周知的RDBMS中（很可能是稳定的、受支持的等），但您仍然可以抽象出一些Object建模能力，这可以（可以说）更适合于开发CRUD应用程序。

我承认我对现代OODBMS的当前功能不是很了解，但除非您所处的领域完全适合实现您域的完美对象表示（而且您有利用对象建模才能利用），否则我会坚持使用RDBMS作为您的持久性存储。

希望这有所帮助！

- jsuggs

0

这基本上解释了利弊：

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

- dseibert

2

那篇文章糟透了。像“OODBMS在某些情况下可能比关系型DBMS更快，因为数据不是以关系行和列的形式存储，而是作为对象存储”，这样的评论完全暴露了对关系模型的无知。如果将“关系型”替换为“SQL”，那么这种说法就有意义了。此外，在百科全书中，结论性的论点是没有存在的必要的。 - Marcelo Cantos

@Marcelo：“在某些情况下可能会更快”，并且（我要补充的是）“在更多情况下可能会更慢”。明天内华达州可能下雨，也可能不下雨 :) - ypercubeᵀᴹ

1

@ypercube：让我感到困扰的不是“可能更快”的部分，而是“关系行和列”。任何对关系模型有超过一般了解的人都知道，它与行和列完全无关，SQL表的行和列只是理论关系、元组和属性的拙劣模仿。 - Marcelo Cantos

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Marcelo Cantos · Accepted Answer

面向对象数据库（OODBMS）的概念相当破碎，过去几十年出现的各种商业和免费产品在市场上几乎没有占据什么优势。

相比于对象模型，关系模型在您对数据提出的问题种类方面更为强大。不幸的是，SQL抛弃了关系模型所能表达的大部分表达能力，但即使是这种被稀释的形式，在SQL中表达查询仍然比典型的OO数据库（无论是ORM还是OODBMS）更容易。

OODBMS中的查询主要由导航操作驱动，这意味着如果您的销售数据库具有销售人员拥有自己的销售记录，则查询给定SKU的月度销售情况不仅可能速度非常慢，而且非常难以表达。同时考虑授予员工访问建筑物的安全模型。哪种方式是正确的？员工是否应持有他们可以访问的建筑物集合，还是建筑物是否应持有能够访问它们的员工集合？更重要的是，为什么任何一个类都必须将另一个类的集合嵌入设计中？而且，无论你选择哪个，你如何询问有哪些员工对可以共同访问多个建筑物？没有直接的导航模式可以回答这样一个问题。明智的解决方案——"访问"对象——本质上是回归到一个经过适当规范化的关系模式，并且需要某种查询语言，该查询语言在很大程度上从关系代数中借鉴，以便在不进行大量数据传输的情况下回答该问题。

另外，考虑到面向对象数据库（OODBMS）所宣传的另一个主要优势：方法，尤其是带有虚拟方法的继承。例如，一个运动诊所可能会为不同类型的运动员设定不同的受伤风险指标。在ORM世界中，这将自动表示为一个类层次结构，以为根，并由每个派生类实现一个虚拟方法。问题在于，这种方法通常在客户端上实现，而不是在后端实现，因此，如果您想找出诊所所有运动项目中最高风险的10名运动员，唯一的方法是通过网络获取所有运动员，并将它们通过客户端优先级队列传递。我对OODBMS的了解不如SQL丰富，但我认为同样存在这个问题，因为存储引擎通常只存储足够的数据以在客户端编程语言中重新生成对象。在关系型模型或SQL中，您可以将受伤风险评分表示为视图，该视图可以简单地是每个运动员类型视图的联合。然后，您只需提出问题。或者你可以问更复杂的问题，比如“谁的伤病风险最大，自上个月检查以来增长最快？”或者“哪个风险评分已被证明是过去一年中最好的受伤预测器？”最重要的是，这些问题都可以在DBMS内回答，只需问题和答案通过网络传输。

关系模型允许DBMS以基于谓词逻辑的高度精炼的方式表达知识，这使得存储在其中的事实的各个维度可以以完全特定的方式进行连接、投影、过滤、分组、汇总和重新排列。它允许您轻松地以未预期的方式处理数据。因此，关系模型允许我们纯粹地表达知识。简而言之，关系模型保存纯事实 - 没有多余的东西，也不会保存对象或代理。

值得一提的是，关系型模型的出现是为了应对当时现有网络和分层式数据库管理系统的灾难状况，并且大部分情况下（基本上是正确的），取代了它们，除了少数应用领域以外（即使这些领域也可能仍然存在是因为SQL未能发挥关系模型的全部威力）。令人深感讽刺的是，现在很多行业基本上正在渴望回到“好旧时光”的网络理论数据库，这本质上就是面向对象数据库管理系统（OODBMSs）和当前NoSQL数据库在回归的方向。这些努力当然批评SQL未能满足当今需求，但不幸的是，他们错误地假定SQL是关系模型的高保真表达，可能是出于纯粹的无知。因此，他们甚至没有考虑关系模型本身，而这个模型几乎没有任何限制，这些限制已经迫使许多人离开SQL，转向OODBMSs。