这里有一个一般性的问题 - 我正在自学MongoDB,为了正确入手,我想知道如何针对一个样例预算应用程序来组织集合。
和任何家庭预算一样,我会有“分类”,比如家庭、汽车,下面还有子类别,比如房贷和车贷。
每个账单都有到期日、最低应付金额、预计付款、预计付款日期、实际付款和实际付款日期。
每个账单都是要付给某个人的,例如家庭中,房贷可能要付给美国银行,而美国银行可能会有联系信息(电话、邮寄地址)。
从表格结构转换到Mongo有点困惑,所以我希望得到任何关于如何处理这个问题的意见。
这里有一个一般性的问题 - 我正在自学MongoDB,为了正确入手,我想知道如何针对一个样例预算应用程序来组织集合。
和任何家庭预算一样,我会有“分类”,比如家庭、汽车,下面还有子类别,比如房贷和车贷。
每个账单都有到期日、最低应付金额、预计付款、预计付款日期、实际付款和实际付款日期。
每个账单都是要付给某个人的,例如家庭中,房贷可能要付给美国银行,而美国银行可能会有联系信息(电话、邮寄地址)。
从表格结构转换到Mongo有点困惑,所以我希望得到任何关于如何处理这个问题的意见。
您的集合布局应受到良好建模原则的指导。使用MongoDB,您可以拥有更接近数据对象结构的模式,而不是关系型数据的“投影”。
您的集合布局应受到数据访问模式(有时可能与前面的语句冲突)的指导。设计您的模式,以便尽可能少地查询所需信息,而不将太多不需要的数据加载到您的应用程序中。
通常情况下,您可以并且应该“去规范化”以实现上述两个目标。这对于MongoDB来说并不是一件坏事。规范化的缺点是更新变得更加昂贵,您需要确保维护一致性。但是这些缺点往往被更自然的建模和更高效的读取效率所抵消。
根据您上述的描述,似乎您已经想到了一个相当“关系型”的模型。试着摆脱它,并以新的思路解决问题。考虑对象,而不是表格。