什么是在流星中处理“复杂”mongodb文档的好方法答案

【问题标题】：What is a good way to handle "complex" mongodb documents in meteor什么是在流星中处理“复杂”mongodb文档的好方法
【发布时间】：2013-01-27 22:14:12
【问题描述】：

我想存储“carpool_debts”，它基本上是用来保存欠其他用户的天数。它看起来像这样：

carpool_debts{
              _id,
              owner,
              owner_id,
              creditors:[{name,
                          id,
                          amount},
                          {name,
                           id,
                           amount}
                        ]}

该数据结构对于我要存储的内容是否合理？此外，实现该数据结构似乎维护起来很麻烦。我发现它很麻烦，主要是因为流星中还没有可用的 upsert 类型的函数。与其将债权人作为子文件列表，不如将债权人存储为分隔字符串？我想知道我是否走在正确的道路上，或者我是否遗漏了什么？谢谢。

【问题讨论】：

标签： mongodb meteor

【解决方案1】：

您可以像在关系数据库中一样构建 mongo 文档，例如，为债权人和所有者提供单独的集合，并使用 carpool_debts 作为附有金额的链接表：

carpool_debts{
              _id,
              owner_id,
              creditor_id,
              amount}

creditors{
          _id,
          name}

owners{
       _id,
       name}

但是，这并没有充分发挥 mongodb 的潜力。特别是如果这是一个包含大量数据的数据库，您可能希望针对最常用的查询对其进行优化，否则会很慢。例如，为了优化查找所有者的债务，您可以在所有者集合中添加所需的数据，为债权人使用子文档，并再次为个人债务使用子文档，类似于您已经完成的操作：

owners{
       _id,
       name,
       creditors: {id,
                   name,
                   debts: {
                           amount,
                           due_date}
                  }
      }

同样，如果您经常查找债权人的未偿债务，请在债权人集合中添加债务信息：

creditors{
          _id,
          name,
          debtors: {
                    owner_id,
                    owner_name, 
                    debts: { 
                             aount,
                             due_date
                           }
                   }
         }

这样，您只需查找一条记录即可获得所需的所有信息。当然，也有陷阱。首先，这不是很干，但这是故意的。但是您必须记住在发生变化时更新其他表。例如，如果您更改债权人的姓名，您将需要更新与该债权人有债务的所有所有者文件（确保将其编入索引）。这当然会使更新更慢（并且数据库更大），但如果您不经常更新，并且更频繁地查找，这不会成为问题。此外，例如，如果债权人可能有数千个未偿债务，您可能必须将其分离到链接表中，或者更确切地说，链接集合，像这样，这样您就不会超过 mongodb 的最大文档大小：

creditors{
          _id,
          name,
         }

debtors: {
           owner_id,
           creditor_id, 
           debts: { 
                    amount,
                    due_date
                  }
          }

然后，对于每个债权人-所有者关系，您都有一份文件。这意味着在查看债权人时需要查找更多文件，但仍然只是用于查找所有者的文件。

【讨论】：

感谢您对我的选择以及每个优点和缺点的解释。

【解决方案2】：

这看起来不错，但您也可以考虑将债权人分成自己的集合，并在债务集合中存储一个债权人 ID 数组。这将降低复杂性并使查找和过滤信息更容易。而且它会更加 DRY，因为如果同一个债权人有多个债务，您只需将债权人存储在一个地方。

您还可以考虑将收债中的每份文件都作为所有者对单个债权人的单一债务。然后你就只有 id、owner_id 和 creditor_id - 就像关系数据库中的链接表。

【讨论】：