我已经很长时间没有从头开始创建一个项目，现在面向文档的数据库(以及ODM)已经变得非常流行，所以我必须在盲目地走向关系路线之前考虑它们。

任何人都可以尝试列出可能导致一种选择或另一种选择的动机/项目标准吗？

优点：

• 众所周知的标准方法
• 很好地映射到具有一致结构的数据
• 很好地映射到多个实体之间具有多个关系的数据
• 具有广泛的连接功能
• 有交易
• 可扩展到每秒大量事务(使用MySQL Cluster，Fusion-IO等)

缺点：

• 如果性能也是一个问题，很难扩展到大量的数据
• 不能很好地映射到具有可变结构(或半结构化)的数据
• 持久化对象需要一个胶水/翻译层，这可能是一个性能瓶颈(如果做错了也可能非常冗长)

ODM /文档数据库/ NoSQL

优点：

• 可扩展到大量数据，以及大量相对独立的查询
• 高可用性，分片，多主，......
• 很好地映射到半结构化数据
• 很好地映射到具有更多可变结构的数据
• 数据模型可以更灵活
• 查询不必转换为SQL(本机NoSQL查询样式可能或可能不适合某些用途，并且没有来自SQL驱动程序/解析/等的开销)
• (对于对象数据库)直接映射到对象，不需要对象关系转换

缺点：

• 通常，没有加入(或限制版本的加入)
• 通常，没有事务(或事务一致性/原子性的有限版本)

怎么决定

根据数据类型和使用模式：

• 数据是否具有统一的结构？ (关系)......或变量/不一致的结构？ (文献)
• 典型用法是读/写单一类型的实体吗？ (文件)......还是由多个实体的属性组成的视图？ (关系)
• 是否需要交易？ (关系)......还是不需要交易？ (文献)

根据扩展/性能要求：

• 巨大的数据+少量，缓慢，复杂的读/写？ (数据仓库类型场景)=>关系
• 巨大的数据+大量简单的读/写？ (craigslist后端类型场景)=>文档
• 巨大的数据+快速，复杂的读/写？ =>这很难;要么使用关系并尝试扩展它，要么使用文档并尝试简化查询
• 中等数据+快速事务写入？ (银行类型场景)=>关系
• 中等数据+适度读/写？ =>根据供应商/工具支持，熟悉程度等选择任何一个

参考

• 何时使用MongoDB或其他面向文档的数据库系统？
• 面向文档的数据库与关系数据库，Doctrine Blog
• NoSQL：如果只是那么容易，BJ Clark
• 关系与非关系，Josh Berkus

(背景：我最近没有在这方面做过任何事情，但几年前我建立了一个使用复制MySQL + Sphinx的大型系统，即关系和文档混合)