对于涉及大量CRUD的常规Web开发，使用对象数据库或关系数据库的缺点和优点是什么？
更新：我重新开启赏金奖励，以便给予内维尔。
答案 0 :(得分：19)
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。
答案 1 :(得分：14)
关系数据库：
优点：
缺点：
OOBDMS
优点：
缺点：
答案 2 :(得分：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的可读性。在网络应用程序中使用ZODB是一个很大的专业人士。
正如马塞洛所说，缺点是缺乏强大的质疑。这部分是上述习语方便的副作用。以下内容完全正常，所有内容都将保存到数据库中：
database.car.colour = "yellow"
database.car.owner = "Trotter"
database.car.neighbour = Car()
但是，这种灵活性使得很难在不同模型之间优化复杂查询。只要列出所有带邻居的黄色车辆，就需要O(n)时间，除非你滚动自己的索引。
因此，这取决于“常规网络开发”的含义。许多网站实际上并不需要复杂的多维查询，并且线性时间内的搜索完全没有问题。在这些情况下，在我看来，使用RDBMS会使代码过于复杂。我只使用对象数据库编写了许多CMS类型的应用程序。很多CRUD并没有特别考虑到它; ZODB非常成熟，可以很好地扩展和缓存。
但是，如果你正在编写一个需要按照谷歌分析的方式进行复杂业务报告的网络应用程序，或者某种具有许多兆兆字节数据的仓库库存管理系统，那么你肯定会想要一个RDBMS。
总而言之，对象数据库可以以复杂查询性能为代价为您提供可读性和可维护性。当然，可读性是一个观点问题，你不能忽视这样一个事实，即更多的开发人员比各种对象数据库方言更了解SQL。
答案 3 :(得分：2)
在常规网站开发中，我在Gemstone上使用Seaside。对于大多数应用程序，这意味着我写零数据库连接代码。它执行，它可以扩展，开发速度提高了大约五倍。
我必须再次使用关系数据库进行Web开发是我必须连接到现有的。
优点：
缺点：
答案 4 :(得分：2)
关系数据库
缺点
对象数据库
缺点
对象关系型数据库（您可能已经看过UDT！）
不同的应用程序可能需要不同的方法（OO，关系数据库或OODB）
参考文献
The advantage of using relational databases for large corpora
Relational Database Relational Database
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
答案 5 :(得分：1)
我认为一切都取决于您问题的具体细节。 （我知道，我真的很喜欢这里。）
我们所知道的是，您希望使用数据库进行Web开发，并且您将对数据进行大量操作。
要问自己的一个相关问题是，DB与您操作的对象紧密集成有多重要？它越是必要，面向对象的DB就越推荐自己。
另一方面，如果您的数据很容易适用于关系模型，那么关系数据库可能会更好。
考虑一下您需要做的操作。您是否需要分析具有不同属性的各种物品？你需要多少资金来证明你的数据库？
我应该补充一点，如果您的数据库可能相当小，性能不会成为主要问题。但是，如果性能实际上是一个问题，除了OO与关系数据库之外，还有许多事情要担心。 （只是从关系数据库世界中选择一个例子，你应该使用什么规范化形式？这是一个非常重要且复杂的问题。你是在维护操作系统还是数据仓库？你是否提前知道某些查询是最重要的，或者可忽略不计的重要性？＆amp; c。）
除了DB性能和与对象模型集成的问题之外，还有其他现实问题要问。您是否有磁盘空间/服务器/带宽限制？您是否只向网络用户提供少量操作，或者您甚至不知道的人是否会创建自己的查询/编辑？
对于其他更重要的现实问题，您将与谁合作？他们已经知道（或更喜欢）什么？如果你还没有领域知识，也许你有个人的好奇心推动你向一个方向发展？如果您正在开始个人项目，那么在您开始之前，遵循自己的偏好是一个更好的成功指南，而不是担心性能。
如果你能回答这些和类似的问题，即使答案是“我不知道”，你也可以更好地指导如何进行。
答案 6 :(得分：1)
在与Marcelo的深度和深思熟虑的回应的合同中，我会说基于你的问题“常规网络开发”的措辞，我的袖口反应将是说你很难被找到足够的专业人员来证明在传统的关系数据库上使用Object DB是合理的，因为更简单的事实是更多的资源/开发人员/教程/等更熟悉传统的关系模型，以及如何利用它来实现“常规Web开发” ”
也就是说，我认为，对于一些现代ORM，您可以获得两全其美的优势，因为您的基础数据存储在一个易于理解的RDBMS中（可能是稳定的，支持的等），但你仍然可以抽象出一些可以（可以说）更适合开发CRUD应用程序的对象建模功能。
我承认我并不精通现代OODBMS的当前功能，但是除非你在一个完全适合你的领域的完美对象表示的领域（并且你有对象建模人才）为了获得优势，我会坚持使用RDBMS进行持久存储。
希望有所帮助！
答案 7 :(得分：0)