Notifikation bei (After-)Post

[DaCoda]

Hallo,
ich habe eine MariaDB und mehrere "ClientApps" im Netzwerk.
Wenn einer etwas "postet", dann sollen die anderen clients informiert werden.
Wie könnte man das lösen ???

[Bernhard Geyer]

z.B. indem du statt direkt in die DB zu schreiben über eine Serverschicht alle DB-Aktionen ablaufen lässt.
Diese Serverschicht sorgt dann für die Verteilung der Benachrichtigungen.

[haentschman]

Moin...
FireDAC kennt sowas...ausprobiert habe ich es noch nicht. Wenn du es hingekriegt hast, kannst du mal ein Tutorial draus machen.
http://docwiki.embarcadero.com/RADSt...erts_(FireDAC)

[Uwe Raabe]

Wenn ich die Liste der unterstützten DBMS für dieses Feature sehe, kann ich weder MariaDB noch MySQL finden. Ich vermute daher, dass es in diesem Fall nicht einsetzbar ist.

[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.