Ansatz gesucht: Triggern einer Benachrichtigung im Kontext von zykl. Dateiabfragen...

[alphaflight83]

Genereller Ansatz gesucht:
Triggern einer Benachrichtigung im Kontext von zyklischen Dateiabfragen kombiniert mit Datenbankzugriff
(Delphi 2009, Datenbank: Firebird 2.5.1 mit UniDac)

Tag Gemeinde,
sorry erstmal für die Prosa, aber wie die Überschrift schon sagt, ist die Situation etwas komplizierter ...

Ich habe für mehrere Clients jeweils eine CSV-Datei mit einer Liste von Meldungen, die ständig aktualisiert werden.
(Dass diese Konstellation an sich schon mal ungeschickt ist weiß ich, das steht aber (leider) momentan nicht zur Disposition)
Jede Meldung besteht aus mehreren Strings und Integern. (StringLists fallen als Container also aus)

1. Die Dateien sollen eingelesen und mit einer Definitionstabelle aus der lokalen Datenbank kombiniert werden. (Edit: Meldungen die nicht mehr in den Dateien auftreten, sollen auch nicht mehr angezeigt werden.)
2. Die aktuellen kombinierten Daten sollen sowohl für jedes Gerät einzeln als auch zusammen angezeigt werden können.
3. Bei einem neuen Eintrag mit gewisser Priorität soll eine Benachrichtigung ausgelöst werden.
Die Einträge lassen sich über den Meldungscode nebst Zeitstempel eindeutig zuordnen.

Das Problem besteht nun darin, wie man diese Kombination möglichst performant hinbekommt.

Momentan besteht eine Lösung, bei der die kombinierten Daten EINES Clients angezeigt werden können.
Das Ganze jedoch ohne Benachrichtigung und ohne Möglichkeit der Anzeige aller Clients.
Hierzu werden ALLE Dateien zyklisch in Stringgrids gelesen und dort die Felder überprüft.
Sollen die Daten eines Clients angezeigt werden, werden die ausgelesenen Daten aus dem jeweiligen StringGrid in eine Datenbanktabelle geschrieben,
dann per SQL mit der Definitionstabelle verknüpft und in ein DBGrid ausgegeben. Das Ganze ebenfalls zyklisch.
Performance-technisch ein Albtraum, da permanent in die Datenbank geschrieben wird.
Zudem kann eben immer nur ein Client angezeigt werden.

Wie könnte man das angehen?
Zyklisches Einlesen der Dateien in StringGrids (oder Arrays) ist denke ich nicht so dumm,
zum Feststellen von Änderungen ein zweiter Satz Arrays, in welche die alten Daten vor dem nächsten Zyklus geschoben werden.
Ob zu einer Meldung bereits eine Benachrichtigung gesendet wurde, könnte dann in einem zusätzlichen Feld des Arrays abgelegt werden,
muss aber bei jeder Aktualisierung beim Vergleich der Arrays nachgezogen werden.

Nun müssen die Arrays noch mit den Daten der Definitionstabelle aus der lokalen Datenbank verknüpft werden,
(Temporäre Tabelle, oder Datenbanktabelle dauerhaft auslesen !?!)
und diese verknüpften Daten für jeden Client einzeln als auch für Alle zusammen abgerufen werden.
Die Benachrichtigung soll ebenfalls die kombinierten Daten enthalten.

Ich bin für jeden Vorschlag und Ansatz dankbar.

[Blup]

Zitat:

1. Die Dateien sollen eingelesen und mit einer Definitionstabelle aus der lokalen Datenbank kombiniert werden.

Daten aus den Dateien sofort in die Datenbank schreiben.
Jeder Datensatz erhält zusätzlich die ID des Gerätes und den Zeitstempel.
Kein Update oder Delete, nur Inserts!

Zitat:

2. Die kombinierten Daten sollen sowohl für jedes Gerät einzeln als auch zusammen angezeigt werden können.

Nur die für die Anzeige notwendigen Daten abfragen und anzeigen.
Dafür passenden Index anlegen.

Zitat:

3. Bei einem neuen Eintrag mit gewisser Priorität soll eine Benachrichtigung ausgelöst werden.

Periodische Abfrage aller neuen DB-Eintragungen (ID oder Zeitstempel > letzte Abfrage) mit gewisser Priorität.
Auch hierfür einen Index anlegen.

[alphaflight83]

Hi Blup,

erst mal Danke für den Beitrag.
Das Problem ist, dass ich um "Delete" nicht rumkomme, da die Meldungen auch wieder verschwinden können und dementsprechend auch nicht mehr angezeigt werden sollen.
(Hab's im Eingangspost editiert)
Wäre das eventuell mit einer temporären Tabelle performanter, oder sollte man da die Verwendung der DB grundsätzlich anders angehen?

[Jumpy]

Zitat von alphaflight83:

Das Problem ist, dass ich um "Delete" nicht rumkomme, da die Meldungen auch wieder verschwinden können und dementsprechend auch nicht mehr angezeigt werden sollen.

Wäre es nicht im Sinne eines vollständigen "loggens" sinnvoller, auch den Zeitpunkt zu speichern, ab dem eine Meldung nicht mehr auftaucht und bei der Anzeige die Meldungen dann halt nicht mehr anzuzeigen?
Mach natürlich was die Datenbankzugriffe angeht, wenig Unterschied, ob du nun einen Datensatz löschst oder "updatest".

[alphaflight83]

Hi Jumpy,

in diesem Abschnitt sind nur die aktuell anliegenden Meldungen wichtig, die am Client noch nicht quittiert wurden, daher ist ein Loggen der Historie hier nicht nötig.
Die alten Daten wären nur ungenutzte Altlasten und die möchte ich möglichst vermeiden.

[Blup]

Wird kein Protokoll benötigt, ist doch alles sehr einfach.
Für jedes Objekt gibts einen Eintrag in der Datenbank mit der letzten Statusmeldung und ob diese quittiert wurde und fertig.

Code:

select * from tabelle where (status = 'kritisch') and (quittiert = 0)

[himitsu]

Wird in allen Dateien oft etwas geändert?

Man kann sich eventuell vom Windows informieren lassen, welche Dateien gerade verändert wurden,
dann müßte mn nicht immer alle Dateien durchgehn, sondern nur die Geänderten.

[alphaflight83]

@Blup:
Ja, die Benachrichtigung kann ich dann mit einem zusätzlichen Feld à la "Bereits gesendet" triggern,
allerdings muss ich in jedem Fall die Datensätze updaten.

@Himitsu:
Ich wusste gar nicht dass das geht, bzw. hab da noch nie drüber nachgedacht.
Das ist auf jeden Fall schon mal nicht schlecht: FILE_NOTIFY_CHANGE_LAST_WRITE
Edit: Hab bei Torry mal die ATFileNotification Compos gezogen, die werd ich mir mal anschauen.

Edit: Nach nochmaligem Nachdenken ist es wirklich die bessere Lösung, die Daten zu behalten
(und irgendwann mal im Paket zu löschen) und Update für die Felder "Quittiert" und "Bereits gesendet" auszuführen.
In Kombination mit Himitsus Vorschlag kann ich vielleicht schon ein gutes Stück Performance rausholen.