Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Notifikation bei (After-)Post (https://www.delphipraxis.net/203159-notifikation-bei-after-post.html)

DaCoda 19. Jan 2020 09:36

Datenbank: MariaDB • Version: 10 • Zugriff über: FireDAC

Notifikation bei (After-)Post
 
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 19. Jan 2020 09:39

AW: Notifikation bei (After-)Post
 
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 19. Jan 2020 10:10

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

Uwe Raabe 19. Jan 2020 10:30

AW: Notifikation bei (After-)Post
 
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 19. Jan 2020 11:10

AW: Notifikation bei (After-)Post
 
..."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 19. Jan 2020 12:50

AW: Notifikation bei (After-)Post
 
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 19. Jan 2020 13:06

AW: Notifikation bei (After-)Post
 
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 19. Jan 2020 17:28

AW: Notifikation bei (After-)Post
 
Würde der EventAlerter funktionieren für diese Aufgabe, wenn ich MSSQL 2017 Express nehmen würde ?

haentschman 20. Jan 2020 06:11

AW: Notifikation bei (After-)Post
 
Moin...8-)
Zitat:

kann ich weder MariaDB noch MySQL finden
...:oops: Ich wußte schon warum ich um MySQL immer einen Bogen gemacht habe. :?

hhcm 20. Jan 2020 06:35

AW: Notifikation bei (After-)Post
 
Zitat:

Zitat von DaCoda (Beitrag 1455537)
Würde der EventAlerter funktionieren für diese Aufgabe, wenn ich MSSQL 2017 Express nehmen würde ?

Nimm PostgreSQL damit gehts definitiv.

TigerLilly 20. Jan 2020 06:58

AW: Notifikation bei (After-)Post
 
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 20. Jan 2020 10:46

AW: Notifikation bei (After-)Post
 
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 21. Jan 2020 06:08

AW: Notifikation bei (After-)Post
 
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 21. Jan 2020 07:06

AW: Notifikation bei (After-)Post
 
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, ...


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:15 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz