我正在构建一个系统，其中有几个表/集合，这些表之间通过“一个/多”到“一个/多”关系进行交互。
事实是，在我目前的方法中，我在文档之间保留了双重引用。例如：
用户属于 0..* 公司；
公司有 0..* 用户；
如您所见，当建立关系时，它会在两个文档中引用 - User.companies 数组更新，Company.users 数组已更新。
因此，我们会根据关系更新两个集合。看来，这样一来，读取（GET）操作将得到优化，因为不需要连接查询；另一方面，写入操作会更慢，因为每个请求可能会请求更新多个文档。
为此，我创建了一个标准化的 CRUD API 来执行主文档及其所有引用的更新；我正在使用猫鼬事务，所以我可以确保操作要么完全完成，要么完全中止，因此不会出现完整性错误。
最后一个问题 - 这是一个好习惯吗？或者，尽管有其优点和缺点，它是否适用/合理/可扩展？
【问题讨论】：
标签： mongodb mongoose transactions relationship crud
一般来说，答案可能是“视情况而定”，正如您可能已经经历过的那样，如果它适合您的要求，您可以使用双重关系。很高兴您认识到您的解决方案在写入方面比读取文档更重，因为在设计 MongoDB 模式时要考虑的事情之一是：您希望您的应用程序是读取密集型还是写入密集型？这是为了节省成本，当然还要确保尽可能优化您的数据库操作。
根据经验，如果可能的话，我不喜欢使用双重关系。仍然存在错误空间（您会感到惊讶），即使我们尝试使用事务、测试等来覆盖这些错误。
最后，这不是最佳做法。例如，对于 Company.users，这不是一个可扩展的解决方案，因为我们不知道可以有多少用户。阅读这篇关于 MongoDB 模式设计最佳实践的文章，规则 4 适用于此。文档的大小是有限制的，更大的文档意味着更慢和更昂贵的操作。
https://www.mongodb.com/developer/article/mongodb-schema-design-best-practices/
规则 4：数组不应无限制地增长。如果多方面有超过几百个文档，请不要嵌入它们；如果多方面有超过几千个文档，请不要使用 ObjectID 引用数组。高基数数组是不嵌入的一个令人信服的理由。
这是一篇非常好的和简洁的文章，我建议您阅读它以更清楚地了解设计模式。
【讨论】：