从实时数据库迁移到云 Firestore 需要对数据库进行全面重新设计。为此，我创建了一个包含一些主要设计决策的示例。
请参阅下面电子表格中的图片和数据库设计。
我的两个问题是:
1 - 当我有一对多关系时，是否也可以选择将信息作为数组存储在文档中？参见数据库设计中的第 8 行。
2 - 我应该只包含一个引用，还是复制一对多关系中的所有信息。请参见数据库模型中的第 38 行。
https://docs.google.com/spreadsheets/d/13KtzSwR67-6TQ3V9X73HGsI2EQDG9FA8WMN9CCHKq48/edit?usp=sharing
最佳答案
一般来说:保持数据存储尽可能浅，即避免子集合和嵌套。
数据可以是一对一的、一对多的或多对多的。 Firestore 是 automatically indexed实时数据存储。 Firestore 通常被订阅，而不仅仅是一次性查询/响应(系统的实时性)。
关于 Firestore 数据模型，请始终考虑如何查询此数据存储？谨慎地(很少)使用子集合、数组和映射，并且仅在必须(并且您很可能不需要)时才使用。使用自动 id 与人类可读的 id，例如使用 000kztLDGafF4uKb8Cal而不是 banana用于文档 ID。
随着应用功能的增加，使用 Cloud Functions for Firebase 和/或 Admin SDK 的服务器端脚本成为管理(创建和索引)多对多数据关系的宝贵工具。例如，Firestore 不支持全文搜索。这归结为在您的应用程序上实现强大的搜索功能似乎是一个障碍。
总之，尽量避免子集合、嵌套、数组和映射。遵循保持简单愚蠢，KISS，原则。一旦您的应用程序扩展和/或需要更多功能，就可以使用服务器端脚本来保持您的应用程序响应(快速)，同时提供强大的功能。
关于firebase - 如何设计 Cloud Firestore 数据库架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47076373/