Database 面向文档的数据库比关系数据库更适合持久化对象吗？

就数据库使用而言，过去十年是ORM的时代，数百人竞相将我们的对象图保存在普通的老式RMDB中。现在，我们似乎正在见证面向文档的数据库时代的到来。它们针对无模式文档进行了高度优化，但由于能够并行扩展和查询集群，因此也非常有吸引力

与RDBMS相比，面向文档的数据库在面向对象设计中持久化数据模型方面也有一些优势。由于表是无模式的，因此可以在继承层次结构中并排存储属于不同类的对象。此外，随着域模型的更改，只要代码能够处理从旧版本的域类中获取对象的问题，就可以避免每次更改都必须迁移整个数据库

另一方面，面向文档数据库的性能优势主要体现在存储更深层的文档时。在面向对象术语中，由其他类组成的类，例如博客文章及其评论。不过，在我能想到的大多数例子中，比如博客，每次添加新评论时都要写整个博客文章“文档”，这似乎抵消了阅读权限的增加

在我看来，如果人们非常小心地将对象组织在深度图中，并针对数据的读写方式进行了优化，那么面向文档的数据库似乎可以为面向对象的系统带来显著的好处，但这意味着提前了解用例。在现实世界中，我们通常不知道，直到我们真正有了一个可以分析的实时实现

---

那么，关系型数据库与面向文档的数据库的情况是摇摆不定的吗？我对人们的意见和建议感兴趣，特别是如果有人在面向文档的数据库上构建了任何重要的应用程序。

这取决于数据的结构和数据访问模式

文档数据库存储和检索文档，基本的原子存储单元是文档。正如您所说，您需要考虑您的数据访问模式/用例来创建智能文档模型。当您的域模型可以在一些文档之间进行拆分和分区时，文档数据库就像一个魔咒。例如，对于博客软件、CMS或wiki软件，文档数据库工作得非常好。只要你能找到一种很好的方法将数据压缩到文档中，你就不会有任何问题。但不要尝试。 一旦数据访问模式在关系上使用了大量的“导航”，图形或对象数据库就会成为更自然的选择

另一件事是关于读/写性能的权衡。例如一个博客软件。在过渡的RDBMS数据模型中，数据是标准化的。这意味着，读取数据是昂贵的，因为读取不同的表、计算与连接的关系等来读取博客文章。作为交换，更改标签是便宜的。 相比之下，在文档数据库中阅读博客文章是便宜的，因为您只需加载文章文档。但是，更新可能更昂贵，因为您需要存储整个文档。或者更糟糕的是，要修改很多文档（重命名标记场景）。在大多数系统中，阅读比写作更重要。因此，使用重整化的数据存储实际上是有意义的

---

我认为在大型数据库上，无模式设计有其优势。在RDBMS中，您需要升级模式，这是一个非常痛苦的过程。特别是将现有数据转换为新模式。在一个无模式的数据库中，应用程序需要处理这个问题，这提供了更大的灵活性。例如，您可以在访问旧文档时动态升级架构。这样，您就可以在应用程序处理较旧版本的同时保持大型数据库的正常运行。

谢谢。我在MongoDB的一次演讲中，演讲者没有很好地阐述关系型和基于文档的比较。这个答案，特别是标签更新的例子，非常有用。