filesystem: daten abgleichen

[Wurzel]

aloah,

ich bin auf der suche nach einer brauchbaren lösung für folgendes problem:

ich erhalte daten von extern (Excel/Access/SQL/csv/etc.pp). diese daten werden extern gepflegt, bearbeitet, aktualisiert. auf diesen vorgang habe ich keinen zugriff, d.h. ich kann ihn nicht beeinflussen. und ich weiss in der regel nicht, ob - und wenn ja, welche - datensätze sich geändert haben.

diese externen daten landen bei mir in einer extra angelegten mysql-db, durchlaufen dann ein script, das den ganzen sums aufbereitet und speziell formatierte textdateien (ASCII) auf die Platte schreibt. diese textdateien sind mit einer anderen software verknüpft (auf die ich keinen einfluss habe), die anhand des dateidatums prüft, ob sich eine datei geändert hat oder nicht. ist das dateidatum verändert, wird die verknüpfung aktualisiert, was unter umständen auswirkungen auf die letztendliche verarbeitung haben kann.

so, mir geht es also darum, NUR die textdateien zu aktualisieren, die sich wirklich geändert haben.

ich hab bislang 2 lösungsansätze:
a) bevor ich den dateiinhalt in die datei schreibe, lese ich dei bestehende datei aus, mache einen stringvergleich und schreibe die daten, wenn ein unterschied besteht.
b) ich speichere in einer eigenen tabelle eine id für den datensatz und einen hash (md5/sha1) des inhaltes, erzeuge im durchlauf einen hash der neuen inhalte, vergleiche den und schreibe die daten, wenn ein unterschied besteht.

(b) finde ich prickelnder, bin mir aber nicht sicher, ob das wirklich bei 300 - 1000 datensätzen hinhaut. aber vielleicht hat ja jemand noch eine andere idee.

[wahsaga]

so, mir geht es also darum, NUR die textdateien zu aktualisieren, die sich wirklich geändert haben.

Mir ist gerade die Richtung, in der dich Veränderung interessiert, nicht ganz klar - willst du von dir weggeschriebene Dateien aktualisieren, wenn sich der Datenstand in der DB ändert; oder willst du deine DB updaten, wenn du "neue" Dateiversionen {unter gleichem Namen?) in dein incoming-Verzeichnis hereinbekommst?

(b) finde ich prickelnder, bin mir aber nicht sicher, ob das wirklich bei 300 - 1000 datensätzen hinhaut.

Wie oft soll das laufen, mit wie vielen Dateien, je a 300 - 1000 DS?

ist das dateidatum verändert, wird die verknüpfung aktualisiert, was unter umständen auswirkungen auf die letztendliche verarbeitung haben kann.

Wenn es um von dir zu schreibende Dateien geht - die könntest du vielleicht auch einfach touch-en, nachdem du sie pauschal und ohne aufwendigere Kontrolle einfach neu schreibst - wenn dir eine andere Möglichkeit zur Verfügung steht, festzustellen, ob eine Änderung vorliegt.
(Wenn z.b. die Datensätze in der DB einen Timestamp haben, dann könntest du alle relevanten in die Datei schreiben, und der Datei den höchsten Timestamp per touch verpassen [wenn die verarbeitende Logik das akzeptiert].)

[Wurzel]

Mir ist gerade die Richtung, in der dich Veränderung interessiert, nicht ganz klar - willst du von dir weggeschriebene Dateien aktualisieren, wenn sich der Datenstand in der DB ändert; oder willst du deine DB updaten, wenn du "neue" Dateiversionen {unter gleichem Namen?) in dein incoming-Verzeichnis hereinbekommst?

ich MUSS die weggeschriebenen daten im filesystem aktualisieren. d.h. die db-daten kommen von extern, z.B. warenwirtschaft. ich baue im grunde genommen eine art schnittstelle zu einer anderen software, die mit einer db nicht umgehen kann. bestehende dateien werden bei einer aktualisierung immer überschrieben, weil eine andere software die verknüpfte datei benötigt.

Wie oft soll das laufen, mit wie vielen Dateien, je a 300 - 1000 DS?

1 ds = 1 datei ... das kann häufiger laufen. der intervall (stunden, tage, monate) ist dabei unabhängig. es ist auch keine webanwendung, die permanent unter last steht.

Wenn es um von dir zu schreibende Dateien geht - die könntest du vielleicht auch einfach touch-en, nachdem du sie pauschal und ohne aufwendigere Kontrolle einfach neu schreibst - wenn dir eine andere Möglichkeit zur Verfügung steht, festzustellen, ob eine Änderung vorliegt.
(Wenn z.b. die Datensätze in der DB einen Timestamp haben, dann könntest du alle relevanten in die Datei schreiben, und der Datei den höchsten Timestamp per touch verpassen [wenn die verarbeitende Logik das akzeptiert].)

so wie ich das sehe, bringt mich touch nicht weiter.

ich versuche es nochmal zu verdeutlichen:

mein datensatz (ds1) beinhaltet zu beginn "blubb", das wird weggeschrieben als "ds1.txt". beim nächsten durchlauf beinhaltet "ds1" immer noch "blubb" => es wird keine datei geschrieben, der ds wird einfach verworfen. im 3.durchlauf hat jemand gemerkt, das "blubb" falsch geschrieben ist, das muss "blabb" heissen. in dem fall muss muss die datei "ds1.txt" neu geschrieben werden. ein einfacher dateigrößenvergleich bringt mit da nicht nach vorne.

dass sich etwas geändert hat (genau das soll mir das system u.a. mitteilen), weiss ich beim durchlauf aber nicht, dass sich dieser datensatz geändert hat, sondern muss das während der laufzeit ermitteln.

ich hab jetzt mit sha1() und sha1_file() experimentiert (das spart mir den zusätzlich db-zugriff). der vergleich funktioniert und scheint mir momentan die beste lösung zu sein.

ein alternative wäre vielleicht noch, bei einer aktualisierung die datenbank zu duplizieren und gegeneinander abzugleichen und quasi nur die differenz zu bearbeiten.

[wahsaga]

dass sich etwas geändert hat (genau das soll mir das system u.a. mitteilen), weiss ich beim durchlauf aber nicht, dass sich dieser datensatz geändert hat, sondern muss das während der laufzeit ermitteln.

Die Datensätze in der DB haben also keinen Timestamp?

Wäre es möglich, eine zusätzliche Spalte dafür einzufügen? Dabei könntest du dir sogar die automatische Aktualisierung von Timestamp-Spalten bei UPDATES zu nutze machen.


DS1 mit Inhalt "blubb" wurde zum Timestamp 2009-07-09 12:01:02 eingetragen.
Dein "Lauf", der Dateien erstellt, lief um 12:30:00, hat die Datei erzeugt.
Der nächste Lauf um 13:00:00 muss nichts machen, weil der Timestamp des DS älter ist als der des letzten Laufes um 12:30:00.
...
DS2 wird mit "blabb" geupdatet, sagen wir "um" 2009-07-09 16:17:43.
Dein nächster Verarbeitungslauf ist um 16:30:00, er weiss das der vorherige Lauf der um 16:00:00 war, selektiert also alle Datensätze mit Timestamp dazwischen - und schreibt für diese neue Dateien.

Ausser den Timestamp an den Datensätzen bei INSERT und UPDATE aktuell zu halten, müsstest du jeweils nur noch den TS des letzten Verarbeitungslaufs speichern - die Auswahl aller Datensätze, die neu geschrieben werden müssen, macht die DB-Query dann für dich.

[Wurzel]

an den mysql-timestamp hatte ich auch schon gedacht aber verworfen, da ich immer den kompletten datenbestand bei einer aktualisierung bekomme . obwohl, "replace" wäre eine option, wenn der timestamp davon unberührt bleibt. mal testen.

edith: bin schon ganz gaga. das nützt mir ja nichts, wenn datensätze gelöscht werden.

[wahsaga]

an den mysql-timestamp hatte ich auch schon gedacht aber verworfen, da ich immer den kompletten datenbestand bei einer aktualisierung bekomme .

Ach so, das war mir noch nicht so klar geworden.

obwohl, "replace" wäre eine option, wenn der timestamp davon unberührt bleibt. mal testen.

Dazu finde ich im Manual auf Anhieb keinen Hinweis.
Aber da es zu REPLACE für den Fall eines vorhandenen Datensatzes sagt, "the old row is deleted before the new row is inserted", wird dabei sicherlich auch der TS upgedatet.
Und dass REPLACE nur auf den primary key oder einen nique index achtet, dürfte das auf Löschen und neu Eintragen in jedem Fall hinauslaufen, wenn du lediglich eine Datensatz-ID als eindeutige Kennung zur Verfügung haben solltest.


Aber man könnte sich vielleicht trotzdem eine Möglichkeit überlegen, beim Einspielen der Daten entsprechende Maßnahmen zu ergreifen.
Als "was" bekommst du den Datenbestand? CSV, fertige SQL-Statements, ...?
Selbst wenn man jeden Datensatz erst mal selektieren und vergleichen würde, kann ich mir das bei einem Umfang von bis zu 1000 Sätzen immer noch performanter vorstellen, als ständig das Dateisystem zu "belästigen". 1000 DS bedeuten dabei ja auch 1000 zu lesende einzelne Dateien, und das kostet vermutlich immer mehr, als die Datenbank zu fragen.

[Wurzel]

Aber da es zu REPLACE für den Fall eines vorhandenen Datensatzes sagt, "the old row is deleted before the new row is inserted", wird dabei sicherlich auch der TS upgedatet.

tut es.
wie edith aber schon sagte, bei gelöschten ds geht es eh in die hose.

ich bleibe jetzt erstmal bei meinem sha1-hash als "prüfsumme". in verbindung mit einer id als eindeutiger bezeichner für den dateinamen, müsste ich erstmal auf der sicheren seite sein.

ich werde parallel mal mit einem duplikat der ds testen und die beim import in der datenbank gegeneinander laufen lassen. die datenbasis ist übrigens je nach kunde immer unterschiedlich. das kann alles mögliche sein ... von plain text bis ms access.

danke dir erstmal für deine bemühungen.