这里只是一个一般性问题 - 我正在对 MongoDB 进行一些自定进度的学习，为了获得正确的结果，我想就如何为示例预算应用程序组织集合提出意见。
与任何家庭预算一样，我有“类别”，例如家庭、汽车，并且我在这些类别下也有子类别，例如抵押贷款和汽车付款。
每张账单都会有一个到期日、最低到期金额、预测付款、预测付款日期、实际付款和实际付款日期。
每张账单都归于“某人”，例如 Home、Mortgage 可能归于 Bank of America，而 Bank of America 可能有联系信息（电话、邮寄地址）。
从 Table 结构切换到 Mongo 有点令人困惑，所以我很欣赏关于如何处理这个问题的任何意见。
这个问题很笼统。一般来说:)，以下原则适用于 MongoDB 中的模式设计：
您的馆藏布局应以合理的建模原则为指导。使用 MongoDB，您可以拥有更类似于数据对象结构的模式，而不是数据的关系“投影”。
集合的布局应以您的数据访问模式为指导（有时可能与前面的陈述冲突）。设计您的模式，以便您可以在尽可能少的查询中获得所需的信息，而无需将太多不需要的数据加载到您的应用程序中。
您通常可以而且应该“非规范化”以实现上述两个目标。对 MongoDB 来说，这根本不是一件坏事。非规范化的缺点是更新变得更加昂贵，您需要确保保持一致性。但这些缺点往往被更自然的建模和更好的读取效率所抵消。
从您上面的描述中，听起来好像您已经考虑了一个相当“关系”的模型。试着摆脱它并以全新的心态解决问题。考虑对象，而不是表格。