如何设计 Cloud Firestore 数据库架构答案

【问题标题】：How to design a Cloud Firestore database schema如何设计 Cloud Firestore 数据库架构
【发布时间】：2018-04-15 00:58:30
【问题描述】：

从实时数据库迁移到 Cloud Firestore 需要对数据库进行全面重新设计。为此，我创建了一个包含一些主要设计决策的示例。请参阅下面电子表格中的图片和数据库设计。我的两个问题是：

1 - 当我有一对多关系时，是否也可以选择将信息作为数组存储在文档中？参见数据库设计中的第 8 行。

2 - 我应该只包含一个参考，还是复制一对多关系中的所有信息。参见数据库模型中的第 38 行。

【问题讨论】：

【解决方案1】：

一般来说：保持数据存储尽可能浅，即避免子集合和嵌套。

数据可以是一对一、一对多或多对多的关联。 Firestore 是一个automatically indexed 实时数据存储。 Firestore 通常被订阅，而不仅仅是一次性查询/响应（系统的实时性）。

关于 Firestore 数据模型，请始终考虑我将如何查询此数据存储？。谨慎地（很少）使用子集合、数组和映射，并且仅在必须（并且您很可能不需要）时才使用。使用自动 id 与人类可读的 id，例如使用 000kztLDGafF4uKb8Cal 而不是 banana 作为文档 ID。

随着应用功能的增加，使用 Cloud Functions for Firebase 和/或 Admin SDK 编写服务器端脚本成为管理（创建和索引）多对多数据关系的宝贵工具。例如，Firestore 不支持全文搜索。这归结为在您的应用程序上实现强大的搜索功能似乎是一个障碍。

总之，尽量避免子集合、嵌套、数组和映射。遵循保持简单愚蠢，KISS，原则。一旦您的应用扩大规模和/或需要更多功能，就可以利用服务器端脚本来保持您的应用响应（快速），同时提供强大的功能。

【讨论】：

“使数据存储尽可能浅” - 我想知道您是否有任何参考资料来揭示这一点？
仅供体验。索引（服务器或云端/预过滤）可以构建虚拟表 - 至少这是一种思考方式。我已经将 150 万个文档加载到一个集合中，一旦我的主要查询类型被索引，它就像我构建了一个专用集合一样快速/响应。浅数据存储意味着更容易编码。 10 次中有 9 次，你不需要另一个收藏。 KISS Principle.
谢谢罗恩。这很有意义。一个简单的问题：您可以看到这种方法的最大缺点是什么？另外我猜您在每个文档中都有类似“类型”字段来维护“虚拟表”方法，因此您可以使用它来获取属于同一“表”的文档，对吗？再次感谢！
没错，我使用type 和category 或其他。我的顶级集合是users、locations、ratings 等。我在这些集合上设置了owner 属性以通过安全规则启用授权/安全。

【解决方案2】：

对于问题 1，firestore 文档中有一个解决方案： https://cloud.google.com/firestore/docs/solutions/arrays

您可以使用值映射并将它们设置为“true”而不是使用数组，这样您就可以查询它们，如下所示：

teachers: {
        "teacherid1": true,
        "teacherid2": true,
        "teacherid3": true
    }

对于问题 2，您只需要保存教师 ID，因为如果您有这些，您可以轻松查询相应的数据。

【讨论】：