建议使用一种方法来构建Firestore数据库,以获得一组深度嵌套的类似电子表格的对象



我的应用程序用于为复杂项目(建筑、媒体制作等(创建生产预算

预算结构如下:预算包含"款",部分包含"帐户"帐户包含"子帐户"子帐户包含行项目。行项目有许多字段(单位、汇率、货币、税收等(和计算的总

或者也许使用Firestore进行这些级联计算是错误的方法?我应该只将一份复杂的预算文档加载到我的应用程序中,对客户端进行所有计算和更新,然后在用户按下"保存预算"时将整个预算作为一份文档写回?

行项目中的某些字段可能具有表示数值的字母数字代码,用户可以使用该代码来代替硬编码数字,例如,用户可以输入"=构建周",并使用计算结果为"7"的公式进行定义,然后在计算总数时使用该公式。

行项目使其总额增加,因此子账户的总额等于其行项目的总和,账户总额等于其子账户的总额,部分合计等于账户合计之和,预算总额是各款总额的总和。

问题是如何将这些数据汇总到构成预算的文件中。预算可能有点长,比如说总共5000行或更多。单个帐户可能有数百个行项目。

用户很可能会查看给定帐户的所有行项目,所以我突然想到为部门、账户和子账户制作单独的文档,并使行项目成为子账户中的映射。

这种方法的主要问题是,当用户更改(比如行项目的货币汇率(或更改命名值的计算值(如"构建周"(时,我必须检索包含该货币或命名值的所有单个行项目,重新计算总数,然后在层次结构中弹出更改。

如果每个行项目都是自己的文档,这似乎没有那么复杂,我可以在集合中搜索有问题的代码,重新计算行项目,并使用云函数来弹出更改。

但是,如果所有行项目都包含在每个子账户映射项目内的映射数组中,在必要的时候找到并更改它们似乎会很乏味。。

另一方面,当有人审查预算时,或者说打印预算时,将这些文档保持得如此之小似乎需要大量的文档阅读。如果有人只是点击一堆账户,那么每次点击可能需要100次阅读才能检索到所有行项目,而当有人更改经常使用的命名值(如"构建周"(的值时,可能需要数百或1000次写入。

有人对这个显而易见的"正确"答案有什么想法吗?还是仅仅取决于我想要优化的内容——firestore成本、应用程序的响应能力、代码的复杂性?

从我的角度来看,您的问题没有明显的答案,实际上这取决于您想要优化的目的。

然而,在你的决定中有几点需要考虑:

  • Firestore中的文档的限制为1Mb/Document;

  • Firestore中的文档限制为20000个字段;

  • 查询是浅层的,因此不会从同一查询的子集合中获取数据;

考虑因素1和2,这意味着如果你选择将数据库中的设计作为一个包含所有内容的大文档,即使你说过你的应用程序会有很多数据,我怀疑它是否会超过上述限制,但请考虑这些限制。此外,一次获取所有数据的必要性如何,这可能代表性能和用户电池/数据使用问题(如果你正在制作移动应用程序(。

考虑因素3,这意味着如果你选择将部分的所有数据划分为子文档,你将不得不进行多次读取,这对你来说意味着更多的成本,但对用户来说意味着更好的性能。

为了对这个问题做出正确的判断,我建议你与解决方案的可能用户交谈,了解你试图解决的问题以及他们对应用程序的期望。此外,看看"如何构建数据和地图、数组和子集合"视频可能会很有趣,因为它们以更直观的方式解释了Firestore的行为,并且有助于预测您选择的方法可能导致的问题。

希望我能帮助解决这些问题。

最新更新