33

似乎我遇到了很多情况，其中构建数据的适当方法是将其拆分为两个文档。假设这是一家连锁店，您正在保存每个客户访问过的商店。商店和客户需要是独立的数据片段，因为它们与许多其他事物交互，但我们确实需要将它们关联起来。

所以简单的答案是将用户的Id存储在商店文档中，或者将商店的Id存储在用户的文档中。通常，您希望访问 1-2 条其他数据用于显示目的，因为 Id 没有用。可能是客户名称或商店名称。

  1. 您通常存储整个文档的副本吗？还是只存储您需要的数据？也许取决于文档的大小与您需要多少。
  2. 您如何处理有重复数据的事实？当数据发生变化时，你会去寻找数据吗？加载时每隔一段时间更新数据？仅在您负担得起陈旧数据时才复制？

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

4

3 回答 3

32

基本上有两种情况：新鲜和陈旧。

新鲜数据

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

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

过时的数据

如果您有能力拥有过时的数据，事情就会变得容易得多。为避免查询开销，您可以存储重复数据。为避免必须维护重复数据，您不会存储重复数据。至少不会主动。

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

概括

仅存储对其他文档的引用。如果您负担得起陈旧数据，请使用定期 map-reduce 作业来生成重复数据。避免维护重复数据；它复杂且容易出错。

于 2010-10-18T08:43:53.977 回答
16

这里的答案实际上取决于您需要数据的最新程度。

@Niels在这里有一个很好的总结，但我认为你可以“作弊”是公平的。

假设您要显示用户使用的商店。这里明显的问题是您不能将商店“嵌入”到用户 b/c 中，因为商店本身就太重要了。但是您可以做的是在 User 中嵌入一些Store 数据。

只需使用您想要显示的内容，例如“商店名称”。所以你的用户对象看起来像这样：

{
  _id : MongoID(),
  name : "Testy Tester",
  stores : [ 
             { _id : MongoID(), "name" : 'Safeway' },
             { _id : MongoID(), "name" : 'Walmart' },
             { _id : MongoID(), "name" : 'Best Buy' }
            ]
}

通过这种方式，您可以显示典型的“网格”视图，但需要一个链接来获取有关商店的更多数据。

于 2010-10-18T16:52:57.683 回答
2

要回答您的直接问题：

  1. 没有重复。
  2. 没有重复。

;)

您应该拥有的唯一重复项是“简单”值，例如权重（可能恰好是相同的，但在单独存储的时间或空间上都没有效率更高），以及引用另一个对象的 ids（它们是重复值，但比它们替换的重复对象数据更小且更易于管理）。

现在，回答您的情况：您想要的是多对多关系。这里通常的解决方案是创建第三个“通过”或“桥接”表/集合，可能称为 StoreUsers：

StoreUsers
----------
storeuser_id
store_id
user_id

您为商店和用户之间的每个链接添加一条记录，无论是针对不同的商店、不同的用户还是一个商店中的一组用户。然后，您可以为商店或用户独立查找此内容。MongoDB 也提倡这种方法。它不是特定于 RDBMS 的。

于 2011-10-09T07:49:23.533 回答