Notifikation bei (After-)Post

[mensch72]

..."Wenn einer etwas "postet", dann sollen die anderen clients informiert werden"...
-> bitte genauer definieren!

Eine allgemeingültige Lösung, welche das komplette beliebig zusammengesetzte oder berechnete SQL-Querrys(also incl. JOINs,...) kann, um jede (Fremd)Feldänderung in beliebiger Tiefe zu erkennen und passend zu benachrichtigen grenzt fast an KI

"kleine&einfache" (Multi)Read/Write Lösungen schafft man z.B. per DBMS-TransactionCommitTrigger, oder ohne DBMS-Beteiligung wenn der "WriteClient" es selbst macht:
- im Trigger dann "ChangeEvents" jeweils als Tripple(Timestamp,Table,PrimaryKey) an eine interne zusätzliche "ChangeEventTable" anhängen
- (Read)Clients pollen(z.B. alle 10sec) dann die "ChangeEventTable" per SQL mit WEHRE auf TimeStamp>"ReadViewTime" und Table+PrimaryKey="UsedReadValues"
- in der "ChangeEventTable" wird z.B. bei jedem belibigem (Client)Programmstart stets alles gelöscht was älter wie 7Tage ist

Die "gepollten" 10sec Verzögerung sind für die meisten Client/GUI Anwendungen, welche irgendwas "dauerhaft" anzeigen akzeptabel. (klar, realtime Börsenkurse sollte man so nicht "verteilen/aktualisieren")
Klar erzeugt sowas dauerhafte zyklische Datenlast im Netzwerk der (SQL)Datenbank... entspricht also nicht der reinen Lehre... aber ich kenne "alte" Anwendungen mit Filebasierten Datenbanken(z.B. DBASE,MS-Access,SQlite), welche nach diesem Prinzip seit zig Jahren sehr stabil Laufen.


Bernhard Geyer hat mit seinem Post ja den Weg für eine "saubere Lösung" aufgezeigt, dagegen geht mein Vorschlag bewusst etwas in Richtung "Quick&Dirty"

[DaCoda]

Es war so gedacht, wenn ich auf Client A einen neuen Datensatz poste, dann müsste man ja bei z.B. Client B refresh drücken damit alles aktuell ist. Und das wollte ich über das Netz irgenwie machen, also praktisch einen refresh überall erzwingen.

FireDAC kann das mit MariaDB nicht so, man muss da selber was machen.
Deshalb überlege ich was gut ist...

Ehrlich gesagt, habe ich nicht so ganz verstanden, was Bernhard Geyer da meint...

Vielen Dank Euch !

[Bernhard Geyer]

Client A -> Server -> Datenbank

Server -> Client B Info über Update
-> Client C Info über Update

Oder wenn das für dich so wichtig ist, schreib gleich einer Webanwendung.
Dann kannst du das alles Anwendungsintern zwischen den Session machen.

[DaCoda]

Würde der EventAlerter funktionieren für diese Aufgabe, wenn ich MSSQL 2017 Express nehmen würde ?

[haentschman]

Moin...

Zitat:

kann ich weder MariaDB noch MySQL finden

... Ich wußte schon warum ich um MySQL immer einen Bogen gemacht habe.

[hhcm]

Zitat von DaCoda:

Würde der EventAlerter funktionieren für diese Aufgabe, wenn ich MSSQL 2017 Express nehmen würde ?

Nimm PostgreSQL damit gehts definitiv.

[TigerLilly]

Vielleicht muss es ja keine aktive Info an die Clients sein. Der Client weiß ja eigentlich, ob er an einer Stelle ist, wo es gut wäre, wenn die Daten aktuell sind + er daher selbst nachschaut.

Im einfachsten Fall hast du in deiner DB daher eine Tabelle mit Arbeitsplatz + einem Schalter aktuell J/N. Wenn ein Client etwas postet, setzt er alle Schalter auf N, seinen eigenen auf J. Jeder Client kann also immer nachschauen, ob er aktuelle Daten hat, bei N, holt er sich die + setzt auf J. Kann man auch granularer ausgestalten.

[himitsu]

Ja, Postgres und andere DBMS bieten Notifications, die man z.B. in einem Trigger auslösen und auf welche das Programm reagieren kann.
https://www.postgresql.org/docs/current/sql-notify.html

Wenn MariaDB sowas nicht bietet, dann muß entweder dein Programm regelmäßig den Inhalt prüfen (pollen), bzw. du benötigst eine Zwischenschicht, welche das für dich macht.
Je mehr Clients, um so besser wäre da ein zwischengeschalteter Dienst, der nur einmal abfragt und die Clients informiert, anstatt jeder Client das selbst macht. (ganz viele Anfragen von vielen Clients)

[DaCoda]

Vielen Dank für die vielen Hilfestellungen

Ich denke ich teste mal PostgresSQL, eventuell erspare ich mir damit die Zwischenschicht etc.


Vielen, vielen Dank Euch !

[mkinzler]

Zitat:

Ich denke ich teste mal PostgresSQL, eventuell erspare ich mir damit die Zwischenschicht etc.

Es gibt auch andere Gründe für eine Zwischenschicht.

Weitere DBMS-Alternativen wären IB/FB, Ingres, ...