Firestore的最佳数据结构设计介于两者之间

Question

我对如何构建我的firestore数据有疑问。

每天，我都有这样的信息：

TodayDate, From, ToUser1, Subject, Attachment2, AttachmentTypeB
TodayDate, From, ToUser1, Subject, Attachment3, AttachmentTypeA
TodayDate, From, ToUser2, Subject, Attachment4, AttachmentTypeA
TodayDate, From, ToUser2, Subject, Attachment5, AttachmentTypeC

Subject和From从不相同。

我在两个结构之间犹豫不决，但我愿意考虑其他结构设计。

0/ Root / doc / sub col / sub col fields
1/ users / userid / date / from,subject,etc
OR
2/ reports / date / userid / from,subject,etc 

我相信，从长远来看，解决方案2将更节省成本，因为对于一个查询，我每个日期的记录将多于每个用户的记录。对于更新，它是类似的。

请问你有什么建议？

问候，

Julie

Answer 1

考虑到您当前的数据结构，我建议您只需使用云firestore而不是实时数据库，因为这样可以更好地扩展，并且可以以非常低的成本获得相当好的性能。

您可以启动一个集合，每个记录都包含您列出的属性：TodayDate, From, ToUser2, Subject, Attachment5, AttachmentTypeC。使用where可以轻松查询：

firestore().collection("myCollection").where("subject", "==", subject).get()

请参阅此比较。

更新：关于您的两个选项，我不认为这取决于哪个选项获取/更新更多/更少的记录。这取决于您的应用程序的要求/实际使用情况。您可能需要获取特定用户的记录，而不仅仅是特定日期的记录，反之亦然。因此，这两种结构在成本方面并没有真正的区别，除非你确信你永远不需要为每个用户获取记录。

因此，我认为主要关注的应该是你的结构有多直观和灵活，以及随着时间的推移维护起来有多容易。您应该首先考虑不使用子集合，因为(从您的日常记录数据来看(您可以实现所需内容，并通过包含具有必要属性的文档的简单集合获得更灵活的结构。我认为，当您不想总是获取记录的所有属性，或者希望实时侦听特定属性而不是整个记录时，通常需要子集合。子集合并没有真正增加/减少提取的记录数量，这取决于的实际使用情况