Firebase Database Design Empfehlung

Ich schreibe eine Anwendung, die Organisation Mitglieder und Zahlungen behandelt. Ich habe folgende Einheiten:Firebase Database Design Empfehlung

Organization---+ 
       | 
       +---Members-----+ 
       |    | 
       |    +---Children 
       +---Accounts 
       | 
       +---Payments

Es> 100.000 Zahlung pro Organisation sein kann, aber nur wenige Mitglieder und Konten. Wenn ein Mitglied eingeloggt ist, kann er nur seine Zahlungen sehen. Wenn Admin eingeloggt ist, sollte er auf alle Daten zugreifen können.

Die Fragen sind:

Soll ich hierarchische Struktur der Organisation zu halten oder sollte ich jede Entität glätten?
Im Fall würde ich die Struktur hierarchisch halten möchte, ist es möglich, eine Organisation mit nur teilweise Untersammlungen zu erhalten (nicht alle Mitglieder und nicht alle Zahlungen)

Dank.

Quelle

2017-02-26 Ronen

Bitte für zukünftige Fragen teilen echte JSON, keine Näherung/Modell. Jetzt haben Sie zwei Antworten, die beide richtig sein können und wir verbringen Zeit damit, herauszufinden, was der andere bedeutet, anstatt Ihnen zu helfen. –

Sie sollten Ihre Struktur flach und möglichst denormalisiert halten. Durch Abfragen des übergeordneten Knotens werden alle untergeordneten Knoten und Daten geladen.

Ja, Sie können Abfrage/Filter immer noch mit dem verfügbaren SDK verwenden.

Quelle

2017-02-26 20:48:18 alltej

Ich stimme nicht sofort zu, aber können Sie erklären * warum * Sie denken, die Daten sollten als eine flache Liste von Zahlungen gehalten werden? –

Hier ist ein Link zum Entwerfen der Firebase Nosql-Datenbank https://firebase.google.com/docs/database/web/structure-data – alltej

Ich bin mit dieser Dokumentation vertraut. Aber ich verstehe nicht, welchen Teil davon du hier für gültig hältst. Die Kombination verschiedener Datentypen in einer einzigen Hierarchie ist fast immer eine schlechte Idee. Aber soweit ich das sehen kann, gilt das hier nicht. Gruppensammlungen sind in der Firebase-Echtzeitdatenbank ziemlich häufig und oft die beste Lösung. –

Bei der Echtzeitdatenbank von Firebase sollten Sie immer die Menge der abgerufenen Daten und die Menge der Daten beachten, die Sie in der Datenbank berücksichtigen.

Wenn Sie die Datenbank als 100K Zahlungen betrachten, um < 10 Zahlungen für den aktuellen Benutzer anzuzeigen, haben Sie eine Menge Ressourcen verschwendet. Ich schrieb mehr darüber hier: Firebase Scalability Limit und Firebase Performance: How many children per node?.

Wenn Sie die Zahlungen für jeden Benutzer einzeln modellieren, reduzieren Sie drastisch die Menge an Daten, die der Server berücksichtigen muss. Dies verbessert die Skalierbarkeit, obwohl natürlich nicht linear.

Wenn der Benutzer admin alle Daten sehen muss, würde ich empfehlen, dass Sie zuerst einen Benutzer auswählen. Danach folgen sie dem gleichen Zugriffsmuster wie normale Benutzer.

Quelle

2017-02-26 22:28:04

Firebase Database Design Empfehlung

Antwort

Verwandte Themen