Datastructure

[vairasza]

Julian und ich haben vorhin wegen der neuen Datastructure in Firebase Real Time Database geredet.

many-to-many Relations :

Die Properties users und groups haben dazu den key der jeweiligen anderen Property gespeichert. D.h. dass beim lösen einer Relation auch beide Einträge gelöscht werden müssen.

one-to-many Relations:

Hier sieht man, dass die zu chats "one" gehörigen members und messages extra gespeichert sind und nicht in seinem subtree vorhanden sind. so können die messages zu chats "one" bei messages über den key referenziert werden. @julian1198 das Problem haben wir ja vorhin besprochen. Firebase selbst scheint vorzuschlagen die Geschichte eher noch flacher zu gestalten.

Demnach würde ich das dann so handhaben:

https://gist.github.com/vairasza/eb9e8b693ac22e6ba41eb6a28a4cbe87

Da haben wir jetzt einmal datastructure_nested.json ==> Tiefe JSON Database

Vorteil:

• es werden zum Start alle Daten auf einmal geladen (außer Updates) und der Nutzer hat dadurch nachfolgend keine Ladeloops mehr

Nachteil:

• hohe Ladezeit zum Start, da der komplette subtree von jedem Kurs geladen wird. (Inklusive Medien aus Firebase Storage)
• es werden auch Daten geladen, welche nicht genutzt werden
• wahrscheinlich schlechte User Experience, wenn die Ladezeit am Anfang sehr hoch ist, weil alle Daten geladen werden müssen.

Und dann haben wir einmal datastructure_flat.json ==> flache JSON Database

Vorteil:

• kleine Datenpakete
• es werden nur Daten geladen, wenn sie gebraucht werden (10GB Limit per Month auf RTD and Storage 5GB)
• best practice laut firebase

Nachteile:

• immer wieder kleine Ladezeiten, wenn ein Kurs geöffnet wird, welcher seit dem Start noch nicht geöffnet wurde

Was meint ihr ist die bessere Lösung? Hat vllt noch jemand andere Argumente? @julian1198 hab ich irgendwas vergessen zu den Alternativen? Ich würde eher die flache Struktur nehmen.

Bezüglich der Codemappings hab ich jetzt einfach ne key-value-Tabelle mit unique ids gemacht, um den tatsächlichen key des Kurses zu kriegen. Muss noch schaun wie der Code am besten aufgebaut ist.

[vairasza]

mein vorschlag zum codemapping wäre jetzt folgender:

man macht nen 6stelligen code mit dem alphabet A-Z (case-insensitive). dadurch ergeben sich etwa 300Millionen verschiedene codemöglichkeiten. denk das reicht und ist recht nutzerfreunlich zum eintippen. implementierung sollte recht straight forward sein.

[julian1198]

Ich würde mich bei der Datenstruktur an die best practice von Firebase halten und die flache Struktur wählen. Bezüglich des Codemappings glaube ich auch, dass ein 8-stelliger Code (ca. 200 Milliarden Möglichkeiten) immer noch nutzerfreundlich ist und in einem Szenario in dem die App an den meisten Unis weltweit genutzt wird auch noch ausreichend ist. Die Attribute, die in der Datenbank gespeichert werden sollten soweit vollständig sein. Eine Überlegung wäre noch, dass man ein Kursbild speichern könnte.