文档数据库：冗余数据,引用等(MongoDB专门)

概述似乎我遇到了许多情况，其中构建我的数据的适当方法是将其拆分为两个文档。让我们说这是一个连锁商店，你节省了每个客户访问过的商店。商店和客户需要是独立的数据，因为它们与许多其他东西相互作用，但我们确实需要将它们联系起来。 因此，简单的答案是将用户的Id存储在商店文档中，或将商店的Id存储在用户的文档中。但很多时候，您希望访问1-2个其他数据用于显示目的，因为Id无用。可能是客户名称或商店名称。 >您通 似乎我遇到了许多情况，其中构建我的数据的适当方法是将其拆分为两个文档。让我们说这是一个连锁商店，你节省了每个客户访问过的商店。商店和客户需要是独立的数据，因为它们与许多其他东西相互作用，但我们确实需要将它们联系起来。

因此，简单的答案是将用户的ID存储在商店文档中，或将商店的ID存储在用户的文档中。但很多时候，您希望访问1-2个其他数据用于显示目的，因为ID无用。可能是客户名称或商店名称。

>您通常存储整个文档的副本吗？或者只是存储您需要的数据？也许取决于文档的大小与您需要的大小。
>您如何处理重复数据的事实？当数据发生变化时，你会追捕数据吗？在加载数据的某个时间间隔更新数据？只有在您能负担得起陈旧数据时才重复？

非常感谢您的意见和/或任何类型的“最佳实践”或至少有充分理由讨论这些主题的链接。

解决方法 基本上有两个场景：新鲜和陈旧。

新鲜数据

存储重复数据很容易。维护重复数据是困难的部分。因此，最简单的方法是避免维护，只需不要存储任何重复数据。如果您需要新数据，这主要是有用的。仅存储引用，并在需要检索信息时查询集合。

在这种情况下，由于额外的查询，您将有一些开销。另一种方法是跟踪重复数据的所有位置，并更新每次更新的所有实例。这也涉及开销，特别是在您提到的N-to-M关系中。无论哪种方式，如果您需要新数据，都会有一些开销。你不可能拥有两全其美。

陈旧的数据

如果您能负担得起陈旧数据，事情会变得容易多了。为避免查询开销，您可以存储重复数据。为避免必须维护重复数据，您不会存储重复数据。至少不积极。

在这种情况下，您还希望仅存储文档之间的引用。然后使用周期性map-reduce作业生成重复数据。然后，您可以查询单个map-reduce结果，而不是单独的集合。这样可以避免查询开销，但您也不必寻找数据更改。

概要

仅存储对其他文档的引用。如果您能负担过时的数据，请使用定期的map-reduce作业来生成重复数据。避免保留重复数据;它很复杂且容易出错。

总结

以上是内存溢出为你收集整理的文档数据库：冗余数据,引用等(MongoDB专门)全部内容，希望文章能够帮你解决文档数据库：冗余数据,引用等(MongoDB专门)所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。