Listen kontinuierlich aktualisieren

[Sir Rufo]

Noch "einfacher" geht es, wenn man zwischen Datenbank und Anwendung eine weitere Schicht einbaut, die genau das regelt.

IdR gibt ein UPDATE-Statement mit gleichen Feldwerten ein RowsAffected mit 0 zurück. Die Zwischenschicht kümmert sich also um das Eintragen und auch wenn ein UPDATE ausgeführt werden soll, dann kann man trotzdem unterscheiden ob wirklich eine Änderung vorliegt und dann entsprechend benachrichtigen.

Die Anwendung selber spricht dann mit der Zwischenschicht und kann sich von der benachrichtigen lassen (Push) oder eben auch nachfragen (Poll), ob sich etwas verändert hat und vor allem was.

Die Zwischenschicht muss auch nicht zwangsläufig Delphi sein.

[Dejan Vu]

Es gibt aber auch Anwendungen, da gehen mal eben tausende von Messages durch, das sind dann keine redundanten Meldungen ("Bei mir tut sich nix").

Beispiel: Ein MES-Interface verbindet eine Maschine in der Produktion mit dem Leitrechner. Wenn sich in der Maschine etwas tut, soll es eine Nachricht an das MES schicken. Das passiert z.B. 1x pro Sekunde ("Stempel xy gedrückt, Bauteil SN 12345 prozessiert etc,")

1. Fall: Es gibt 1000 Maschinen in einer etwas größeren Fabrik, also hab ich kontinuierlich 1000 Messages pro Sekunde. Da kann ich mit Schichten arbeiten, oder nur Änderungen verschicken, es bleiben einfach 1000 Messages pro Sekunde.

2. Fall: Die Verbindung zum MES ist unterbrochen. Das MES benötigt aber alle Nachrichten. Also puffert das Interface die Daten und sobald die Verbindung wieder steht, werden die Daten nachträglich rübergeblasen. Natürlich muss das schneller gehen als 1x pro Sekunde und die Daten sollen ja auch möglichst schnell wieder in Echtzeit abgeleifert werden, also fluten diese Nachrichten den Empfänger.

Im 2.Fall habe ich z.B. nur 10 Queues, die mir im Normalfall die Nachrichten pro Maschine anzeigen. Logischerweise ganz einfach als 10 Grids mit jeweils sekündlichem Update. Ist ja kein Ding.... nur wenn dann die Verbindung mal unterbroche wurde, und dann anschließend die gepufferten Daten rüberkommen, habe ich kurzzeitig z.B. pro Maschine 100 Nachrichten pro Sekunde. Und dann geht mein eigentlich vollkommen ausreichendes Nachrichtenanzeigesystem für mehr oder minder kurze Zeit in die Knie.

Auch hier würde eine Anfrage "Was hat sich denn geändert?" zur Antwort:"50.598 Zeilen" führen, was widerum ein Anzeigeproblem verursacht.

Die Überlegung ist doch die: Wozu dient die Anzeige? Will man wirklich alles in Echtzeit sehen oder will man doch eigentlich nur sehen, das etwas passiert (und im Groben auch: WAS passiert)?

Natürlich sollte man Empfang und Speicherung einerseits und die Darstellung andererseits trennen, vielleicht oder mit Sicherheit sogar auch hardwaretechnisch. An einen 24/7 Server werden nun einmal andere Ansprüche gestellt als an eine Leitwarte.

Sinnvollerweise würde ich die Speicherung in einem SQL-Server vornehmen, womit sich die Zwischenschicht schon erschlagen hat, denn das kann das Teil ja von alleine. Auch Notifications lassen sich mit den meisten RDBMS erledigen. Aber auch hier gilt: Bloß die Anzeige nicht fluten.

Wenn man nun die Daten in einem DB-Grid darstellt und das DB-Grid fragt einfach 2x pro Sekunde "Select top 20 * from DatenTabelle order by Zeitstempel", dann ist vollkommen egal, wie viele Daten in die Tabelle reingepustet werden. Ich bekomme 2x pro Sekunde die aktuellsten 20 Sätze. Ob die sich ändern oder nicht oder ob zwischen zwei Abfragen 750 Mio neue reingekommen sind, ist wurscht. Wichtig ist nur, das ein geeigneter Index auf der Zeitstempeltabelle ist, damit das sortieren nichts kostet.

Alternativ dazu kann das RDBMS auch einen Statussnapshot der Maschinen generieren (per Trigger) und die Clients fragen diesen Snapshot einfach ab. Wieder wird keine Zwischenschicht benötigt.

Ich stehe auf dem Standpunkt, das ich den Grad der Komplexität in einem System nicht unnötigerweise erhöhen sollte. Und zusätzliche Dienste, Schichten etc. können diesen Grad eben erhöhen (Und sie tun dies in den meisten Fällen auch): Noch eine Konfig, noch ein System, was crashen und Probleme verursachen kann etc.

Natürlich: Habe ich 100te unterschiedlicher und frei konfigurierbarer "Maschinen" bzw. Statusse (nein: nicht Stati), die ich pflegen muss, werde ich einen Teufel tun, das in der DB mit Triggern zu bewerkstelligen denn da ver X-fache ich meinen Komplexitätsgrad gerade durch das *Weglassen* von zusätzlichen Dienern.