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