我认为在选择存储后端时，数据格式应该是首要考虑的问题。您是否具有关系相关的数据？如果是这样，可以对文档中的数据建模吗？数据建模在文档数据库中与在关系数据库中一样重要，只是做了不同的事情。您有几种类型的对象，它们之间有什么关系？Mongodb中的DBrefs可以解决问题吗？还是您会错过外键，这会很痛苦吗？您对数据的访问方式是什么？您是仅获取由字段值过滤的一种类型的数据，还是具有复杂的获取模式？

您需要ACID交易完整性吗？域是否对数据施加了很多约束？您是否需要文档数据库的可伸缩性因素，或者仅仅是“很酷”的事情？

您的一致性和数据完整性要求是什么？为了获得性能，某些NoSQL解决方案（尤其是MongoDB）在写入一致性方面过于宽松。NoSQL并非统一的环境，其他产品也不例外，例如CouchDB在该部门具有其他特征。有些也是可调的。

这些都是应该选择存储的所有问题。

一些经验

• 使用MongoDB或任何文档数据库时，对存储的数据进行大量报告可能会比较困难，并且某些用例已为此目的将RDBMS和document-db结合在一起。
• （非常）不同的查询模型。MongoDB也不同于其他document-db。
• 在开发过程中可以灵活地更改数据格式/模式
• 未知地区
• 驱动程序和框架的成熟度各不相同
• 快速地
• 更简单（在许多方面）的产品和管理工具（与许多RDBMS产品相比）
• 不再有阻抗不匹配的情况。存储适合数据，而不是相反。
• 减少摩擦，更直接地访问数据。
• 域与持久性息息相关（取决于NoRM的ORM“级别”，取决于它抽象化了后端的多少。我没有使用NoRM，所以我无法回答。）