Opened by lousek at 2011-02-24 00:10
User since
2006-05-04
564 Artikel
BenutzerIn
2006-05-04
564 Artikel
BenutzerIn
Hallo Lousek,
wenn ich es recht verstehe, geht es (zumindest unter anderem) darum, die History einer Verzeichnisstruktur zu protokollieren. Oder?
Hierzu ist es m.E. nicht erforderlich, die Struktur hierarchisch zu speichern, sondern ich würde wohl zu dem Pfad-Modell neigen.
Zu den von Dir gesehenen Nachteilen:
- Der Aufbau des Baumes scheint mir durchaus nicht schwierig zu sein: Es genügt doch, die Pfade alfabetisch zu sortieren (bzw. von der DB sortieren zu lassen). Um eine hübsche Verzeichnisbaum-Ansicht zu bekommen, kann man ja bei der Anzeige per RegEx oder
File::Spec alles links vom letzten / abtrennen und in Abhängigkeit von der Anzahl der / einrücken (sinngemäß).
- Es wird schon einiges an Platz benötigt, aber das sollte bei Verwendung eines RDBMS nicht weiter schlimm sein. Dafür sind die Dinger ja da. (Die Ansätze, alles gleichzeitig im Arbeitsspeicher verarbeiten zu wollen, können hingegen durchaus am Datenumfang scheitern.)
Ich stelle mir eine Datenbanktabelle vor, die z.B. im Wesentlichen folgende Spalten hat:
Primärschlüssel wäre FULLPATH und FIRSTDETECTED (auf jeden Fall UNIQUE) oder die ID (letzteres ist dann sinnvoll, wenn später Fremdschlüssel darauf verweisen, z.B. aus der 1:n-verknüpften Tabelle mit den Dateinamen darin usw., sonst wäre die ID verzichtbar).
DIRNAME und LEVEL sind natürlich prinzipiell verzichtbar, sie werden aus FULLPATH generiert (s.o.). Zu entscheiden ist, ob sie schon beim INSERT oder erst später bei der Ausgabe von der Anwendung erzeugt werden sollen.
Die beiden Datumsfelder bilden die Zeit ab, in der ein Verzeichnis exisitiert hat. FIRSTDETECTED wird auf (jetzt) gesetzt, wenn das Verzeichnis erstmals erfasst und INSERTed wird, LASTVERIFIED wird bei jedem Synchronisationsvorgang auf (jetzt) gesetzt. Bei der Abfrage des aktuellen Filesystems wird in der WHERE-Klausel auf LASTVERIFIED = (Datum_der_letzten_Synchronisierung) gefiltert.
Für die Synchronisation, also den Abgleich mit dem wirklichen Filesystem, sind verschiedene Ansätze denkbar, je nach den Anforderungen, ich beteilige mich auch hier gern an der Diskussion, wenn gewünscht.
Soviel fürs erste
Grüße
payx
PS: Was auf jeden Fall sehr schwer verfolgbar ist, sind Fälle, in denen Verzeichnisse umbenannt oder verschoben werden. Sie müssen wohl (bei allen derartigen Ansätzen) als Löschung und Neuanlage registriert werden.
Editiert von payx: Typo
Last edited: 2011-02-24 14:28:27 +0100 (CET)
wenn ich es recht verstehe, geht es (zumindest unter anderem) darum, die History einer Verzeichnisstruktur zu protokollieren. Oder?
Hierzu ist es m.E. nicht erforderlich, die Struktur hierarchisch zu speichern, sondern ich würde wohl zu dem Pfad-Modell neigen.
2011-02-23T23:10:51 lousek### Pfad-Modell ###
- Jeder Datensatz besteht aus ID und pfad.
# Vorteil #
- Es kann einfach einen ganzen Pfad abgefragt werden
- Es kann einfach überprüft werden, ob ein Pfad bereits in der DB ist
# Nachteil #
- Der Aufbau des Baumes gestaltet sich eher schwierig, da in der Datenbank keine Hierarchie abgebildet ist
- Es wird viel Platz gebraucht, da immer der komplette Pfad gespeichert wird
Zu den von Dir gesehenen Nachteilen:
- Der Aufbau des Baumes scheint mir durchaus nicht schwierig zu sein: Es genügt doch, die Pfade alfabetisch zu sortieren (bzw. von der DB sortieren zu lassen). Um eine hübsche Verzeichnisbaum-Ansicht zu bekommen, kann man ja bei der Anzeige per RegEx oder
File::Spec alles links vom letzten / abtrennen und in Abhängigkeit von der Anzahl der / einrücken (sinngemäß).- Es wird schon einiges an Platz benötigt, aber das sollte bei Verwendung eines RDBMS nicht weiter schlimm sein. Dafür sind die Dinger ja da. (Die Ansätze, alles gleichzeitig im Arbeitsspeicher verarbeiten zu wollen, können hingegen durchaus am Datenumfang scheitern.)
Ich stelle mir eine Datenbanktabelle vor, die z.B. im Wesentlichen folgende Spalten hat:
Code: (dl
)
1
2
3
4
5
6
ID NUMERIC
, FULLPATH VARCHAR
, DIRNAME VARCHAR
, LEVEL NUMERIC
, FIRSTDETECTED DATE
, LASTVERIFIED DATE
Primärschlüssel wäre FULLPATH und FIRSTDETECTED (auf jeden Fall UNIQUE) oder die ID (letzteres ist dann sinnvoll, wenn später Fremdschlüssel darauf verweisen, z.B. aus der 1:n-verknüpften Tabelle mit den Dateinamen darin usw., sonst wäre die ID verzichtbar).
DIRNAME und LEVEL sind natürlich prinzipiell verzichtbar, sie werden aus FULLPATH generiert (s.o.). Zu entscheiden ist, ob sie schon beim INSERT oder erst später bei der Ausgabe von der Anwendung erzeugt werden sollen.
Die beiden Datumsfelder bilden die Zeit ab, in der ein Verzeichnis exisitiert hat. FIRSTDETECTED wird auf (jetzt) gesetzt, wenn das Verzeichnis erstmals erfasst und INSERTed wird, LASTVERIFIED wird bei jedem Synchronisationsvorgang auf (jetzt) gesetzt. Bei der Abfrage des aktuellen Filesystems wird in der WHERE-Klausel auf LASTVERIFIED = (Datum_der_letzten_Synchronisierung) gefiltert.
Für die Synchronisation, also den Abgleich mit dem wirklichen Filesystem, sind verschiedene Ansätze denkbar, je nach den Anforderungen, ich beteilige mich auch hier gern an der Diskussion, wenn gewünscht.
Soviel fürs erste
Grüße
payx
PS: Was auf jeden Fall sehr schwer verfolgbar ist, sind Fälle, in denen Verzeichnisse umbenannt oder verschoben werden. Sie müssen wohl (bei allen derartigen Ansätzen) als Löschung und Neuanlage registriert werden.
Editiert von payx: Typo
Last edited: 2011-02-24 14:28:27 +0100 (CET)