Vor- und Nachteile
Die Nachteile von Realtime Datenbanken gegenüber herkömmlichen Datenbanken hängen von der Implementierung und dem Optimierungsgrad der Datenbank ab. Wenn das Szenario sehr zeitkritisch ist, dann wird die Implementierung und Optimierung der Datenbank darauf hinauslaufen, dass die Vorteile (Relationen, Querys, Schemata) von klassischen RDBMS nicht zum tragen kommen werden, da die Vorteile durch Rechenkraft erkauft werden und dies kostet Zeit. Aber der Aspekt der Echtzeit-Verbreitung der Ereignisse selbst muss keinen Nachteil mitbringen, wenn das Szenario nicht die Definition "so schnell wie technisch möglich" hat. Dann kann, wie in Kapitel Technische Aspekte erläutert, jede Datenbank zu einer Realtime Datenbank erweitert werden.
Ein Vorteil von Realtime Datenbanken ist es, vereinfachte Schnittstellen zu haben, um an Datensätze zu gelangen, die sich stetig verändern bzw. erweitern. Anstatt, dass eine Client-Anwendung immer wieder mit einer Anfrage an eine REST-Schnittstelle arbeitet, um nach neuen Daten zu fragen und diese darzustellen, kann es in modernen Rich Client Applikationen ausreichen, wenn diese sich einmalig an einem WebSocket registrieren und die Daten ohne weitere Verarbeitung anzeigen.
Dies kann dann so ausgebaut werden, dass ein three-way-data-binding vorliegt. In modernen Rich Client Applikationen wird häufig das two-way-data-binding genutzt, um den Status der Client-Anwendung im Model (MVC-Pattern) aus der View heraus zu verändern. Mit dem three-way-data-binding ergibt sich nun die Möglichkeit, dass die Realtime Datenbank eine Aktualisierung bekommt (von einer beliebigen Quelle aus; sei es eine andere Client-Anwendung oder einer externen Schnittstelle), dieses Ereigniss wird dann zu allen Client-Anwendungen propagiert und dadurch wird der Status der jeweiligen Client-Anwendung im Model verändert und diese Veränderung spiegelt sich dann auch in der Veränderung der View wieder. Durch die vereinfachte Schnittstelle der Realtime Datenbank (zum Beispiel Firebase) kann das in wenigen Zeilen Code ermöglicht werden.
Abbildung: Szenario Four-Way-Data-Binding mit mehreren Client-Anwendungen
In der Abbildung wird das three-way-data-binding zum four-way-data-binding erweitert. Die vierte Komponente ist in dem Fall das LocalStorage, das dazu genutzt wird, um die Daten auch offline speichern und erreichen zu können. Wenn das Szenario die Nutzung des LocalStorages eines WebBrowsers nicht zulässt, kann auch eine andere lokale Datenbank genutzt werden. Diese lokale (offline) Datenbank muss unbedingt synchron zur Realtime Datenbank sein. Jede Veränderung der Realtime Datenbank muss synchronisiert werden, sodass die Abfragen der Client-Anwendung sich direkt an die lokale Datenbank wenden und nicht an die Realtime Datenbank.