问Web开发- Object db与Relational

EN

关系数据库：

优点：

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

缺点：

• 阻抗与OO概念不匹配-在数据库中建模“继承”是不自然的。
• 层次结构通常需要对语言进行特定于供应商的扩展。
• 非关系数据(例如文档)并不是一种自然的适合。
• 一旦定义了模式，就很难实现业务域中的更改。

OOBDMS

优点：

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

缺点：

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

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

关系模型在数据类型问题方面比对象模型更强大。不幸的是，SQL抛弃了关系模型所能具备的表达能力，但即使在这种稀释的形式下，用SQL表示查询仍然比在典型的OO数据库(无论是ORM或OODBMS)中更容易。

OODBMS中的查询主要由导航操作符驱动，这意味着如果您的销售数据库中有销售人员拥有他们的销售，那么查询给定SKU的每月销售可能会非常缓慢，而且很难表达。还可以考虑一种安全模型，允许员工访问建筑物。哪种表达方式是正确的？员工应该拥有他们可以访问的一批建筑，还是应该拥有一批能够访问这些建筑的员工？更重要的是，为什么任何一个类都必须将另一个类的集合放入其设计中？而且，无论你选择哪一种，你怎么会问哪对员工有不止一栋他们可以共同进入的大楼？没有直截了当的导航模式可以回答这样的问题。明智的解决方案--“访问”对象--实质上是回归到适当标准化的关系模式，它需要某种从关系代数中大量借用的查询语言来回答这个问题，而不需要进行大规模的跨线数据传输。

还请考虑OODBMS的另一个主要优点:方法，特别是使用虚拟方法的继承。对于不同类型的运动员，体育诊所可能有不同的受伤风险指标。在ORM世界中，这将自动表示为类层次结构，根处为Athlete，每个派生类实现了一个虚拟方法( int InjuryRiskScore() )。问题是，这种方法总是在客户端实现，而不是在后端实现，所以如果您想在诊所找到所有运动项目中的10位风险最高的运动员，唯一的方法就是让所有运动员通过网络并通过客户端的优先级队列。我也不了解OODBMS世界，但我认为也会出现同样的问题，因为存储引擎通常只存储足够的数据，以便在客户端的编程语言中对对象进行重新水合物处理。在关系模型或SQL中，您可以将受伤风险评分表示为视图，这可以是每个运动员类型观点的统一。然后，你就问这个问题。或者你可以问更复杂的问题，比如“自上个月体检以来，谁的受伤风险增长最大？”甚至，“哪个风险得分被证明是过去一年伤病的最佳预测指标？”最重要的是，所有这些问题都可以在DBMS中得到回答，而仅仅是通过网络传递的问题和答案。

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

从历史的角度来看，关系模型的出现是为了应对当时存在的网络和分级DBMS的灾难性状况，并且在很大程度上(而且正确地)取代了所有应用程序领域中的所有应用程序(甚至这些应用领域可能仍然存在，很大程度上是因为SQL未能提供RMs功能)。极具讽刺意味的是，许多行业现在基本上都渴望网络理论数据库的“好时光”，这基本上就是OODBMS和当前的NoSQL数据库正在回归的方向。这些努力正确地批评了SQL未能满足当今的需求，但不幸的是，它们错误地(可能出于纯粹的无知)假定SQL是关系模型的高保真表达。因此，他们甚至忽略了关系模型本身，而关系模型本身几乎没有导致许多人离开SQL的限制，而这些限制往往是针对OODBMS的。

我可以就我熟悉的一个对象数据库回答您的问题：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)时间，除非你自己滚动索引。

所以，这取决于你所谓的“定期网络开发”是什么意思。许多网站实际上不需要复杂的多维查询，线性时间内的搜索根本不是问题。在这些情况下，在我看来，使用RDBMS可能会使代码过于复杂。我只使用对象数据库编写了许多CMS类型的应用程序。很多CRUD并没有特别深入；ZODB非常成熟，而且规模和缓存都很好。

但是，如果您正在编写一个web应用程序，需要按照Google Analytics的方式进行复杂的业务报告，或者是某种具有许多兆字节数据的仓库库存管理系统，那么您肯定需要一个RDBMS。

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