Eins zu viele Beziehung In Firebase

Question

Ich habe eine Firebase-Datenbank. Ich habe Job-Objekte und Item-Objekte. Jeder Job kann viele Items enthalten und ein Item muss in einem einzelnen Job enthalten sein (Simple One to Many). Meine aktuelle Datenbankstruktur besteht darin, dass sowohl Artikel als auch Job Top-Level-Listen in Firebase sind und jeder Artikel den jobKey enthält, zu dem er gehört. Dies ermöglicht mir, alle Elemente in einem Job zu finden, solange ich den Jobschlüssel kenne. Der Firebase-Code, um die Elemente zu finden, erfordert eine Abfrage, die ein "orderBy" auf dem jobKey in den Elementen enthält. So ist es einfach, alle Artikel für einen Job abzurufen. Ich möchte aber auch die Elemente basierend auf zusätzlichen Daten in den Elementen sortieren und filtern. Aber wegen der Firebase-Einschränkung eines einzelnen "orderBy" kann ich diese zweite Stufe der Filterung mit Firebase nicht erreichen. Das ist meine Herausforderung. Die Struktur meiner gegenwärtigen Daten ist unten dargestellt.

+--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 

Wie bereits erwähnt, mag ich in der Lage sein, alle Elemente für einen Auftrag abholen und dann bestellen und Filtereinzelteile durch verschiedenes Feld in dem Eintrag. Angesichts der oben genannten Struktur ist die einzige Möglichkeit (die ich sehe), die Firebase-Abfrage zu verwenden, um die Elemente abzurufen, und dann Logik in der Komponente zu verwenden (ich benutze angular2), um alle Elemente in eine Art Sammlung zu cachen Sortieren und Filtern basierend auf den zwischengespeicherten Daten. Das ist nicht sehr befriedigend, es muss einen besseren Weg geben. Was sind die vernünftigen Alternativen?

Answer 1

Ich habe mit der Lösung kommen.

Eine alternative Möglichkeit, die Daten zu strukturieren ist zu nisten die Elemente direkt in einer Jobliste. Dies wird unten veranschaulicht. Dies ermöglicht die Verwendung von Firebase-Abfragen zum Ordnen und Filtern innerhalb der Artikeldaten. Dies scheint eine gute Lösung zu sein, aber es hat Skalierungsnachteile.

+--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> 

Auf Nachteile dieser Lösung ist, dass es nicht sehr gut skalieren, wenn die Itemlisten groß sind, da jede Lese des Jobs alle Artikel liest. Und in meinem Fall, wenn ich das Job-Objekt lese, möchte ich nicht die gesamte Artikelliste lesen, sondern ich möchte einen Verweis auf die Artikelliste erstellen und die Firebase-Abfrage-/Filterfunktion in der Artikelliste verwenden. Es gibt also keinen direkten Vorteil, wenn Sie die Artikelliste in den Job einfügen. In meiner Anwendung ist die praktische Grenze Hunderte von Elementen. Obwohl die Lösung wahrscheinlich für meine Anwendung funktionieren wird, muss es eine bessere, besser skalierbare Lösung geben.

Eine bessere Lösung.

Nach weiterem Nachdenken besteht die beste Lösung für dieses Problem darin, Item-Listen zu erstellen, die für einen Job spezifisch sind, aber nicht im Job-Objekt enthalten sind. Wenn ein Job gelesen wird, muss die gesamte Liste nicht vorhanden sein lesen. Und wir behalten auch die Fähigkeit bei, Daten in der Artikelliste basierend auf ihren Daten zu sortieren/zu filtern. Diese Struktur ist nachstehend veranschaulicht. Artikellisten für jeden Job werden unter dem Pfad "Artikellisten/< jobKey>/Artikel"

+--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