使用对象数据库或关系数据库进行涉及大量 CRUD 的常规 Web 开发的优缺点是什么？
更新：我重新打开赏金奖励是为了给内维尔。
问问题
6102 次
8 回答
20
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 是关系模型的高保真表达。
于 2011-03-19T03:38:04.613 回答
17
关系型数据库：
优点：
- 成熟的技术——大量的工具、开发人员、资源
- 广泛的开源和商业产品
- 已知可扩展到非常大的站点和非常高的吞吐量
- 以逻辑和“可编程”的方式表达许多问题域
- 相当标准的语言（SQL）
缺点：
- 与 OO 概念的阻抗不匹配 - 在数据库中建模“继承”是不自然的
- 分层结构通常需要对语言进行特定于供应商的扩展
- 非关系数据（例如文档）不是天生的
- 一旦定义了模式，业务领域的变化就很难实现
OOBDMS
优点：
- 更适合 OO 概念
- 理论上，开发人员只需要使用一种语言工作——持久性细节被抽象掉了。这应该会提高生产力
缺点：
- 可用的工具/资源/开发人员显着减少。
- 没有被广泛接受的标准
- 持久性的“黑盒”方法会使性能调优变得困难
- 持久性细节经常泄漏到 OO 设计中（参见 Marcelo 的示例）
于 2011-04-08T12:36:15.427 回答
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 所述，最大的缺点是缺乏强大的查询功能。这部分是上述成语方便的副作用。以下是完全OK的，一切都会被持久化到数据库中：
database.car.colour = "yellow"
database.car.owner = "Trotter"
database.car.neighbour = Car()
然而，这种灵活性使得跨不同模型优化复杂查询变得困难。O(n)除非您滚动自己的索引，否则仅列出所有有邻居的黄色汽车将需要时间。
因此，这取决于您所说的“常规 Web 开发”是什么意思。许多网站实际上并不需要复杂的多维查询，线性时间的搜索完全没有问题。在这些情况下，我认为使用 RDBMS 会使您的代码过于复杂。我已经编写了许多只使用对象数据库的 CMS 类型的应用程序。很多 CRUD 并没有特别涉及它。ZODB 非常成熟，并且可以很好地扩展和缓存。
但是，如果您正在编写一个需要按照 Google Analytics 的方式进行复杂业务报告的 Web 应用程序，或者某种具有许多 TB 数据的仓库库存管理系统，那么您肯定会想要一个 RDBMS。
总而言之，对象数据库可以以复杂的查询性能为代价为您提供可读性和可维护性。当然，可读性是一个见仁见智的问题，您不能忽视这样一个事实，即了解 SQL 的开发人员比各种对象数据库方言要多得多。
于 2011-04-08T15:01:18.857 回答
3
在常规的 Web 开发中，我使用 Seaside on Gemstone。对于大多数应用程序，这意味着我编写零数据库连接代码。它执行、扩展、开发速度大约快五倍。
我将再次使用关系数据库进行 Web 开发的唯一一次是当我必须连接到现有数据库时。
优点：
- 更少的代码，更快的开发；
- 更好的可扩展性；
- 可以处理更复杂的模型；
- 更好的项目敏捷性；
- 我提到过灵活性吗？
- 可以处理类模型的变化，不仅是数据，还有代码；
缺点：
- 您可能必须自己培训开发人员；
- 您想要的（宝石）对于大型系统来说要花很多钱
于 2011-04-09T15:59:22.297 回答
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
于 2011-04-16T11:38:22.173 回答
1
与 Marcelo 的深入和深思熟虑的回应相吻合，我想说的是，根据您对“常规 Web 开发”问题的措辞，我的即兴回应是说您很难找到足够的专业人士为了证明使用对象数据库而不是传统的关系数据库是合理的，因为更多的资源/开发人员/教程/等更熟悉传统的关系模型，以及如何利用它来实现“常规 Web 开发”。
也就是说，我认为使用一些现代 ORM，您可以获得两全其美的好处，因为您的基础数据存储在一个易于理解的 RDBMS（可能是稳定的、受支持的等）中，但是您可以仍然抽象出一些可以（可以说）更适合开发 CRUD 应用程序的对象建模功能。
我承认我并不精通现代 OODBMS 的当前功能，但是除非您所在的领域完全适合实现您的领域的完美对象表示（并且您有对象建模才能可以利用)，那么我会坚持使用 RDBMS 来进行持久存储。
希望有帮助！
于 2011-04-06T20:21:35.453 回答
1
我认为一切都取决于您的问题的具体情况。（我知道，我在这里真的很危险。）
我们所知道的是，您想使用数据库进行 Web 开发，并且您将对数据进行大量操作。
要问自己的一个相关问题是，数据库与您操作的对象紧密集成有多重要？越是必要，面向对象的数据库就越推荐自己。
另一方面，如果您的数据很容易适用于关系模型，那么关系数据库可能会更好。
想想你需要做的操作。您是否需要分析具有不同属性的各种项目？您需要多少才能使您的数据库面向未来？
我应该补充一点，如果您的数据库可能相当小，那么性能将不是主要问题。但是，如果性能实际上是一个问题，那么除了 OO 与关系数据库之外，您还有很多事情要担心。（仅从关系数据库世界中选择一个示例，您应该使用哪种规范化形式？这是一个非常重要且复杂的问题。您是在维护操作系统还是数据仓库？您是否提前知道某些查询是是最重要的，还是微不足道的？&c.)
除了数据库性能和与您的对象模型集成的问题之外，还有其他现实世界的问题要问。你有磁盘空间/服务器/带宽限制吗？您是否会仅向 Web 用户提供少量操作，或者您甚至不认识的人可能会创建自己的查询/编辑？
对于其他更重要的现实问题，您将与谁合作？他们已经知道（或喜欢）什么？如果您还没有领域知识，也许您有个人好奇心将您推向一个方向？如果您正在开始一个个人项目，那么遵循自己的喜好比在开始之前担心性能更好地指导成功。
如果你能回答这些和类似的问题，即使答案是“我不知道”，你也能在如何进行时获得更好的指导。
于 2011-04-04T09:08:05.043 回答
0
于 2011-03-18T21:54:01.033 回答