我想知道Firestore数据库的最佳结构是什么。
我想为员工创建某种约会管理器，在这里我可以向每个员工显示某个日期的约会。我想到了这两种选择：
每个员工都有一个集合Appointments，我将在其中保存所有即将到来的约会。任命文件将具有一列date。
当我要加载某个日期的所有约会时，我将不得不查询该日期之前的所有约会。
每个员工都有一个集合Workdays，其中包含每天的文件。这些工作日文档的列为date。然后是Appointments的集合，我将约会保存在一个工作日。
当我要加载所有约会时，我将不得不向Workdays集合查询正确的日期，然后加载其所有Appointments。
我希望平均每个工作日包含10至20个约会。假设我保存了接下来30天的约会。对于选项1，我将不得不查询300-600个文档，直到10-20个。
对于选项2，我将有30个文档，并向其中查询1个文档。然后加载大约10-20个文档。
因此，在选项2中，我将不得不查询较少的文档，但是必须等到查询完成后再加载10-20个其他文档。对于选项1，我将不得不查询更多文档，但是一旦查询完成，就不必再加载任何文档。
我想知道对于我的用例来说，哪种选择更快？有什么想法吗？
答案 0 :(得分：2)
文档不一定是表格形式（列）。保持简单，遵循他们的文档Choose a data structure，不要过分考虑优化搜索。将查询优化留给Firebase平台/团队使用，因为可能要实施多种搜索方法，具体取决于要查询的数据类型。示例包括source Wikipedia：
Dijkstra算法，Kruskal算法，最近邻居 算法和Prim的算法。
同样，如果您基本上遵循其数据结构准则，则最佳搜索方法应纳入Firebase / Firestore平台，并在可能时对其进行优化。简而言之，计算平台的速度会让您赞叹不已。专注于与您的特定应用有关的高级任务。
答案 1 :(得分：1)
如果在每种情况下已读的文档总数相同，则更快的选项将是减少客户端和服务器之间往返次数的选项。因此，总查询越少越好。集合中的文档总数不会对结果产生很大影响。
使用Firestore，查询的性能取决于结果集的大小（读取的文档总数），而不取决于集合的总大小。
答案 2 :(得分：1)
第一个选项非常简单，绝对是您使用关系数据库进行操作的方式。假设甚至需要一个日期，日期列可能成为任何潜在工作日表的自然外键。
第二种方法更为复杂，因为存在三种数据情况：
在性能方面，它们之间可能不会有很大差异，但是如果存在很大差距，我会赌选项1来提高效率。