这里只是一个普遍的问题 - 我正在MongoDB上做一些自学的学习并且正确地走下去我想知道如何为样本预算应用程序组织集合。
与任何家庭预算一样，我有＆＃39;类别＆＃39;例如Home，Auto和我在这些类别下也有子类别，如抵押贷款和汽车支付。
每张账单都有截止日期，最低到期金额，预测付款，预测付款日期，实际付款和实际付款日期。
每个账单都是由某人提供的，例如Home，Mortgage可能是由于美国银行，而美国银行可能有联系信息（电话，邮寄地址）。
从Table结构切换到Mongo有点令人困惑，所以我很感激有关如何处理这个问题的任何意见。
答案 0 :(得分：1)
问题非常笼统。通常:)，以下原则适用于MongoDB中的模式设计：
您的馆藏布局应遵循合理的建模原则。使用MongoDB，您可以拥有一个更接近数据对象结构的模式，而不是它的关系“投影”。
您的馆藏布局应遵循您的数据访问模式（有时可能与之前的语句冲突）。设计您的模式，这样您就可以在尽可能少的查询中获得所需的信息，而无需在应用程序中加载过多的数据。
您经常可以而且应该“反规范化”以实现上述两项目标。对MongoDB来说，这不是一件坏事。非规范化的缺点是更新变得更加昂贵，您需要确保保持一致性。但是这些缺点往往被更自然的建模和更好的阅读效率所抵消。
从上面的描述中，听起来好像你已经考虑过一个相当“关系”的模型。试着摆脱这种情况，以一种清新的头脑来解决问题。想想对象，而不是表格。