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

使用对象数据库或关系数据库进行涉及大量 CRUD 的常规 Web 开发有何优缺点？

更新：我重新打开了赏金奖励，以便给内维尔。

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

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

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

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

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

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