我有一个Firebase数据库。我有Job对象和Item对象。每个作业可以包含多个项目,并且一个作业(简单的一对多)必须包含一个项目。我目前的数据库结构是Item和Job都是firebase中的顶级列表,每个Item都包含它所属的jobKey。只要我知道作业 key ,就可以找到作业中的所有项目。用于查找项目的firebase代码需要一个查询,该查询在项目中的jobKey上包含“orderBy”。因此,很容易检索工作的所有项目。但是,我也想根据项目中的其他数据对项目进行排序和过滤。但是由于单个“orderBy”的firebase限制,我无法使用firebase完成第二级过滤。这是我的挑战。我当前数据的结构如下所示。

+--jobs
  |
  +-- jobKey1
  |  |
  |  +-- <jobdata1> ..
  |
  +-- jobKey2
     |
     +-- <jobdata2>..

+--items
  |
  +-- itemKey1
  |  |
  |  +-- jobKey : jobKey2  // this item belongs to job2
  |  |
  |  +-- <the rest of item1 data
  |
  +-- itemKey2
  |  |
  |  +-- jobKey : jobKey2  // this item belongs to job2
  |  |
  |  +-- <the rest of item2 data
  |
  +-- itemKey3
  |  |
  |  +-- jobKey : jobKey1  // this item belongs to job1
  |  |
  |  +-- <the rest of item3 data
  |
  +-- itemKey4
     |
     +-- jobKey : jobKey1  // this item belongs to job1
     |
     +-- <the rest of item4 data

如前所述,我希望能够检索作业的所有项目,然后按项目中的各个字段对项目进行排序和过滤。给定上面的结构,(我看到的)唯一的方法是使用firebase查询来检索项目,然后在组件中使用逻辑(我正在使用angular2)将所有项目缓存到某种集合中,然后根据缓存的数据进行排序和过滤。这不是很令人满意,必须有更好的方法。有哪些合理的选择?

最佳答案

我想出了解决方案。

一种结构化数据的替代方法是将项目列表直接嵌套在Job中。如下所示。这样就可以使用Firebase查询对商品数据进行排序和过滤。这似乎是一个很好的解决方案,但它具有缩放方面的缺点。

   +--jobs
      |
      +-- jobKey1
      |  |
      |  +-- <jobdata> ..
      |  |
      |  +-- items
      |     |
      |     +-- itemKey3
      |     |  |
      |     |  +-- <the rest of item3 data>
      |     |
      |     +-- itemKey4
      |        |
      |        +-- <the rest of item4 data>
      |
      +-- jobKey2
         |
         +-- <jobdata>..
         |
         +-- items
            |
            +-- itemKey1
            |  |
            |  +-- <the rest of item1 data>
            |
            +-- itemKey2
               |
               +-- <the rest of item2 data>

该解决方案的一个缺点是,如果项目列表很大,它的伸缩性就不会很好,因为每次读取作业都会读取所有项目。就我而言,当我读取Job对象时,我不想读取整个项目列表,而是想创建对项目列表的引用,并在项目列表上使用firebase查询/过滤器功能。因此,将项目列表放置在Job内实际上并没有直接的好处。在我的应用程序中,实际限制是数百个项目。因此,即使该解决方案可能适用于我的应用程序,也必须有一个更好的,更具可伸缩性的解决方案。

更好的解决方案。

经过进一步考虑,解决此问题的最佳解决方案是创建特定于作业但不包含在Job对象中的Item列表,以便在读取Job时不必读取整个列表。而且,我们还保留了根据其数据对项目列表中的数据进行排序/过滤的功能。下面说明了这种结构。每个作业的项目列表保存在路径“itemlists//items”
+--jobs
   |
   +-- jobKey1
   |  |
   |  +-- <jobdata1> ..
   |
   +-- jobKey2
      |
      +-- <jobdata2>..

 +--itemlists
   |
   +-- jobKey1    // items list for job1
   |  |
   |  +--items
   |    |
   |    +-- itemKey3
   |    |  |
   |    |  +-- <the rest of item3 data
   |    |
   |    +-- itemKey4
   |    |  |
   |    |  +-- <the rest of item4 data
   |
   +-- jobKey2    // items list for job2
      |
      +--items
        |
        +-- itemKey1
        |  |
        |  +-- <the rest of item1 data
        |
        +-- itemKey2
           |
           +-- <the rest of item2 data

09-10 10:06
查看更多