Hallo Delphi.Narium,
ich bin nicht ganz sicher ob Du nur die Hash-Verwaltung beschreibst, oder ob Hash und Tree-Verwaltung zusammen integriert sind.
Ich hatte ja schon geschrieben, dass dies vielleicht zwei verschiedene Aufgaben sind, die man nicht mischen sollte.
Persönlich fände ich das Mischen beider Aufgaben aber sehr sinnvoll, eben weil es dann keine Redundanzen und Fehler durch getrente Datenhaltung auf das gleiche physikalische System geben kann.
Ich meine Du beschreibst das aufnehmen der Hashes in die
DB usw., und dann nur am Rande, dass daraus Tree, ListView usw. erstellt werden können.
Welche Struktur schlägst Du denn dafür vor?
Ich sehe dafür erstmal zwei sinnvolle Optionen in einer
DB, vielleicht gibt es aber noch weitere:
Delphi-Quellcode:
-- Adjacency List
CREATE TABLE FileSystem (
id INT PRIMARY KEY,
parent_id INT,
name VARCHAR(255),
hash_value VARCHAR(255),
type VARCHAR(50),
FOREIGN KEY (parent_id) REFERENCES FileSystem(id)
);
-- Nested Set
CREATE TABLE FileSystem (
id INT PRIMARY KEY,
name VARCHAR(255),
lft INT,
rgt INT,
hash_value VARCHAR(255),
type VARCHAR(50)
);
In jedem Fall ist der "hash_value" sozusagen nur ein nützliches Abfallprodukt, mit dem sehr schnell verifiziert werden kann,
ob es eine Datei bereits im System gibt und wie oft, unabhängig von der zu Grunde liegenden Baumstruktur.
Das trifft das was ich suche schon ganz gut, danke sehr für die Idee mit der
DB, das scheint eine Menge Vorzüge über einer spezifischen Klasse zu haben.
Meine Frage war zu Deiner Erfahrung mit "Adjacency List" bzw. "Nested Set" oder eventuell auch "Flat table" mit kompletten Pfadangaben,
was davon sich für das Durchlaufen von Filesystemen am besten eignet.
Ich muss wahrscheinlich öfters die gesamten Filesysteme abgleichen, eben weil es mehrere Parteien gibt, welche unabhängig voneinander darauf zugreifen können.
Remote-Verzeichniss (es kann mehrere geben)
- ist ein zentrales Filesystem mit entfernten Daten, gehostet auf einem Fileserver im Internet
- es kann durchaus mehrere, redundante oder auch ergänzende Remote-Verzeichnisse geben, auf verschiedenen Servern
- dieses kann auf verschiedenen Wegen bearbeitet werden (z.B. automatisch aus einem anderem Dokumentenmanagementsystem, manuell per Website)
- kann über verschiedene Protokolle bearbeitet werden (z.B.
FTP, REST-
API, direkt über WebClient auf dem Serversystem)
- das von verschiedenen Parteien aus bearbeitet werden kann (automatische Ausleitungen von verschiedenen Systemen)
- eine Verwaltung von Änderungen, Verzeichnisbaum auf dem Server ist erstmal nicht so ohne Weiteres möglich.
- die Möglichkeit eine
DB auf dem Server zu halten, welche das Ganze zentral abbildet, wäre denkbar ist aber auch eher ungewünscht.
Lokal
- ist eine lokale Kopie zur Zusammenführung, Bearbeitung und Analyse spezifischer Daten (lokal um den Server nicht zu belasten)
- die lokale Kopie sollte möglichst nur bei Änderungen aktiv werden, daher die Frage nach Vergleich ganzer Baumstrukturen mit Hash
- insbesondere das Einstellen neuer Dateien soll abgeprüft und verhindert werden (das gleiche File, mit anderem Namen, an andere Stelle).
Eine Möglichkeit wäre noch das Erzeugen und Speichern von Fingerprints (*.md) auf den Servern, was aber auch eher ungewünscht ist.
Die Datenmengen sind jedenfalls nicht so groß, dass eine Synchronisation Remote-Lokal generell ein Problem wäre.
Deshalb trifft der Vergleich zu GIT/GitHub von Benmik schon ganz gut zu, nur eben geht es in erster Linie um binäre Dateien, nicht nur um Text.
Es gäbe noch einen anderen Vergleich, z.B. mit einem
FTP-Client, welcher auch Locale und Remote Filesysteme abgleichen kann,
aber nicht unbedingt Änderungen in den Files erkennen kann.
Ich denke der Ansatz mit einer
DB ist einen Versuch Wert, das werde ich mal nächste Woche angehen.