问题描述
|
这个问题已经在这里有了答案：
解决方法
我发现有用的一些经验法则是：
如果某条信息只有一个逻辑副本，则该副本应位于一个文档中（例如，如果您对某个帖子有评论，最简单的方法是将其嵌入到该帖子中）
如果要在SQL中将数据非规范化到另一个表中以避免连接或其他原因，则在文档存储中也会出现相同的行为：从一个“主”位置非规范化为其他位置的副本。副本应被视为副本，而不是原始信息，因此将来的非规范化操作可以将其覆盖。
如果您必须从多个位置访问一组规范的数据集（例如用户帐户），则将引用存储为mongodb中的“ 0”，然后对相关文档执行第二次查询。您必须在应用程序中知道第二个查询不是联接，并且不会锁定两个文档以确保一致性，因此结果中可能存在不一致之处。
本质上，您应该认为数据库在文档级别上是一致的。对相关文档的任何查询都可能不一致，因此，如果需要一致性，可以将该数据反规范化为一个文档。
如果您需要用户帐户与注释完全一致，则必须在将注释写入文档的同时复制注释旁边的相关信息。这意味着您必须始终在应用程序级别上考虑一致性。如果不是这样（我怀疑是这种情况），只需向用户发出另一个查询。
如果您担心在查询参与页面的所有用户的数据时的性能，建议您从注释旁边的用户帐户中复制一些数据，但只能从该副本中读取-您应写成原始用户帐户。
这就是现在的所有想法，但是我可能会随着事情的发生而编辑:)
, 之所以麻烦，是因为MongoDB不是关系数据库，而是面向文档的数据库。对于一些简单的东西，例如带有非常固定的结构和一对多关系的注释树，您最好还是坚持使用MySQL。用户配置文件可能对于使用MongoDB来说是一件有趣的事情，但是同样，如果它非常结构化，那么使用MySQL可能会更好。
您可能想要确定项目的哪些方面最适合面向文档的数据库（IE：非结构化数据），哪些方面最适合使用更传统的关系数据库，然后同时使用两者！
我问的上一个问题对以下两个方面都有很好的概述：面向文档的数据库是否打算取代关系数据库？
我也一直在两个项目上都成功使用过，尽管它确实需要大量的初始设置，因为大多数框架都不允许太容易地实现这两个框架。