在数据库使用方面，过去十年是ORM的时代，有数百人争相在普通的老式RMDBS中坚持我们的对象图。现在，我们似乎正在目睹面向文档的数据库时代的到来。 These databases针对无架构文档进行了高度优化，但对于扩展和并行查询群集的能力也非常具有吸引力。
面向文档的数据库与RDBMS相比还具有一些优势，可以在面向对象的设计中持久保存数据模型。由于表是无模式的，因此可以将属于不同类的对象并排存储在继承层次结构中。此外，随着域模型的更改，只要代码可以处理从旧版本的域类中获取对象，就可以避免在每次更改时都迁移整个数据库。
另一方面，面向文档的数据库的性能优势主要出现在存储更深层文档时。在面向对象的术语中，由其他类组成的类，例如，博客文章及其注释。在大多数这样的例子中，我可以提出，例如博客，读取访问的收益似乎被每次新评论时必须写整个博客文章“文档”的惩罚所抵消。加入。
在我看来，面向文档的数据库可以为面向对象的系统带来显着的好处，如果人们非常谨慎地组织深度图中的对象，这些图是针对数据读写方式而优化的，但这意味着知道预先使用案例。在现实世界中，我们经常不知道，直到我们实际上有实时实现，我们可以分析。
关系型与面向文档的数据库是一个波动和环形交叉口的情况吗？我对人们的意见和建议感兴趣，特别是如果有人在面向文档的数据库上构建了任何重要的应用程序。
答案 0 :(得分：5)
这取决于您的数据结构和数据访问模式。
文档数据库存储和检索文档和基本原子存储单元是一个文档。正如您所说，您需要考虑数据访问模式/用例以创建智能文档模型。当您的域模型可以在某些文档中拆分和分区时，文档数据库就像魅力一样。例如，对于博客软件，CMS或维基软件，文档数据库非常有效。只要您能找到将数据压缩到文档中的好方法，就不会有任何问题。但是不要试试to fit a relational-model into a document-database。 一旦数据访问模式在关系上使用了大量“导航”，图形或对象数据库就是更自然的选择。
另一件事是关于读/写性能的权衡。例如博客软件。在过渡RDBMS数据模型中，数据被标准化。这意味着，读取数据是昂贵的，因为从不同的表中读取，计算与连接等的关系以阅读博客帖子。作为交换，更换标签很便宜。 相比之下，在文档数据库中阅读博客文章很便宜，因为你只需加载文档。但是更新可能更昂贵，因为您需要存储整个文档。或者更糟糕的是，通过大量文档来改变一些东西（重命名标记场景）。在大多数系统中，阅读比写作更重要。因此，使用重整化数据存储实际上是有意义的。
我认为在大型数据库中，无架构设计可以发挥其优势。在RDBMS中，您需要升级模式，这是一个非常痛苦的过程。特别是将现有数据转换为新模式。在无架构数据库中，应用程序需要处理它，这提供了更大的灵活性。例如，您可以在访问旧文档时动态升级架构。这样，您可以保持巨型数据库的正常运行，同时应用程序可以动态处理旧版本。