Ich habe eine parse.com-basierte App mit Offline-Funktionen, bei der die gesamte Datenbank lokal gespeichert wird (localStorage auf Web-Clients und parse.com lokale Datenbank auf mobilen Clients). Ich suche nach einer Designlösung, um die lokale Datenbank mit den neuesten Änderungen in der entfernten Datenbank effizient zu aktualisieren. Die Möglichkeiten, die ich mir vorstellen kann, sind:
Journaling mit Code-Triggern . Richten Sie Cloud-Code-Trigger (afterSave, afterDelete) für jedes Objekt ein und fügen Sie der Journaltabelle jedes Mal ein Protokoll hinzu, wenn ein Objekt gespeichert oder gelöscht wurde. Die Clients fragen die Tabelle nach Updates ab und merken sich lastUpdateTime für nachfolgende Anfragen.
Pros: a) wir können eine sehr detaillierte Zusammenfassung haben, was geändert wurde und wer die Änderung vorgenommen hat. b) alle Änderungen sind sofort für andere Clients verfügbar (z. B. kann ein Tabellenanruf für Benachrichtigungen in Echtzeit mit geringen Verzögerungen abgefragt werden)
Nachteile: a) Es gibt möglicherweise zu viele Einträge in der Tabelle
Journaling mit Hintergrundjob . Richten Sie einen Hintergrundjob ein, der alle Tabellen nach updatedAt abfragt, die Journaltabelle auffüllt und die lastUpdateTime für nachfolgende Anforderungen speichert.
Vorteile: a) weniger Einträge in der Journaltabelle
Nachteile: a) Änderungen sind mit unvorhersehbarer Verzögerung verfügbar (nicht für Echtzeit-Benachrichtigungen geeignet?) b) kann keine Löschungen verfolgen, es ist immer noch notwendig, eine weitere Tabelle einzurichten, um Löschungen nachzuverfolgen oder Soft-Delete zu implementieren c) weniger Details in der log (zB wenn ein Objekt von einem Benutzer erstellt und von einem anderen Benutzer gelöscht wird, wissen wir nicht, wer ein Objekt erstellt hat)
Kein Journal . Alle Clients fragen alle Tabellen nach updatedAt ab und speichern lastUpdateTime für nachfolgende Anforderungen.
Vorteile: a) einfach zu implementieren, b) Änderungen sind sofort verfügbar
Nachteile: a) dasselbe Problem mit Löschungen wie in 2 , b) ineffizient (ich glaube, dass die Abfrage von 20+ Tabellen von allen Clients keine gute Idee ist
Wir haben auch eine Benutzeroberfläche, auf der der Nutzer die aktuelle Aktivität sehen kann (wer hat was geändert), also lehne ich mich an Nummer 1 an, aber die potenzielle Größe des Tisches beunruhigt mich.
Der Client muss unabhängig vom aktuellen Status wiederhergestellt werden können. Dies ist kritisch, wenn Sie lokalen Speicher verwenden, der vom Benutzer möglicherweise gelöscht wird. In diesem Fall benötigen Sie einen wiederherstellbaren Zustand. Zusätzlich muss der Client in der Lage sein, nur die für ihn erforderliche Transaktion abzurufen.
Abschließend - Modifiziertes Journaling mit Code-Triggern (Modifiziert, um den Status für den Client im Server wiederherzustellen und zu speichern und damit die Daten abzufragen)
Tags und Links javascript database parse.com database-design