如何设计Cloud Firestore数据库架构

Question

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

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

2 - 我是否应仅包含引用,或复制一对多关系中的所有信息.请参见数据库模型中的第38行.

Answer 1

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

数据可以是一对一、一对多或多对多相关的。Firestore 是一个自动索引的实时数据存储。Firestore 经常被订阅，而不仅仅是一次查询/响应（系统的实时性）。

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

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

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

仅经验。索引（服务器或云端/预过滤）可以构建虚拟表 - 至少这是一种思考方式。我已经将 150 万个文档加载到一个集合中，一旦我的主要查询类型被索引，它的速度/响应速度就像我构建了一个专用集合一样。浅数据存储意味着更容易编码。十有八九，你不需要再收集一次。[KISS 原则](https://en.wikipedia.org/wiki/KISS_principle)。 (2认同)

Answer 2

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

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

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

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