Question

我正在Firestore中构建一个任务管理应用程序。 Tasks可以有多个members和tags。由于我将始终对用户的内容进行排序和显示（基于截止日期，优先级等），并且由于firestore具有列表和复合索引的限制，因此我最终将数据存储在以下结构中。

projects:

.....   
    101: {
        name: 'task1', 
        members: {201: true, 202: true, ......}, 
        tags:{'tag1':true, 'tag2':true, 'tag3':true,....} 
      },

    102: {
        name: 'task2', 
        members: {201: true, 202: true, ......}, 
        tags:{'tag1':true, 'tag2':true, 'tag3':true,....}
      },

    103: {
        name: 'task3', 
        members: {201: true, 202: true, ......}, 
        tags:{'tag1':true, 'tag2':true, 'tag3':true,....} 
      }

.....

现在，由于复合索引必须是手动的，所以我最终实现了反向查找：

users:
.....

201: {
        name: 'John',
        tasks: 
                501: {taskId: 601, priority: high, ...... },
                502: {taskId: 601, priority: high, ...... },
                503: {taskId: 601, priority: high, ...... },            
     }

202: {
        name: 'Doe',
        tasks: 
                504: {taskId: 601, priority: high, ...... },
                505: {taskId: 601, priority: high, ...... },
                506: {taskId: 601, priority: high, ...... },            
     }

......

这时，如果您也必须过滤tags，在用户下，我将必须为每个标记添加子集合并将任务存储在它们之下。这将为每个任务创建大量的文档。例如，如果您有一个包含3个成员和3个标签的任务，则此设置将仅为一个任务创建12个文档。我所做的任何更改都将涉及12次写入。

我在这里想念什么？这是我存储数据的方式吗？还是更多与Firestore本身功能不足有关？

Answer 1

Firestore在查询上确实有局限性
我看到的是您正在尝试对数据进行规范化，如果您正在使用RDBMS，这是一个很好的方法。在Firestore中，通常建议尽可能对数据进行规范化。但是，这又是一个折衷，您的读取将很快且易于查询，但写入可能会很慢，因为您可能必须在多个位置写入数据。
反规范化-简单来说，它具有扁平的数据结构

好读- https://angularfirebase.com/lessons/firestore-nosql-data-modeling-by-example/

使用Firestore进行过滤和排序

1 个答案: