Optimaler Hash-Algorithmus und Strategie für Dateivergleiche, Verzeichnisbaum

[Rollo62]

Zitat von Delphi.Narium:

Die Daten bilde ich immer in 'ner Datenbanktabelle ab

Interessant, das ist auch eine Möglickeit.
Ich bin bisher davon ausgegangen, dass es wohl zu langsam wäre, aber stimmt, das muss es ja gar nicht.
Wie verwaltest Du denn da die Baumstruktur, mit selbst-referenzierten Keys in einer Tabelle?
Vielleicht hast Du dafür schon eine optimale SQL-Struktur gefunden, Baumstrukturen in einer DB sind etwas problematisch.

Mit FDMemTable könnte das schon ziemlich performant sein, vielleicht sogar mit sqlite, was noch weitere Vorteile hätte.

Was mich bisher nicht auf den Gedanken gebracht hat, war, das ich sowas wie ein Einlesen aller Verzeichnisse oder
ein Hinzufügen von Verzeichnissen einbauen möchte.
Mit Unterverzeichnissen und Dateien, da könnte eine DB etwas schwächeln, gegenüber einen optimierten Speicherliste mit Hash-Option.

Eigentlich wollte ich die Struktur immer on-the.fly laden, und dabei auf Änderungen prüfen,
aber ja, eine permanente DB würde das regelmäßige Einladen sparen.

Zitat von Michael II:

Ich würde auch Parameter, welche rasch zu gewinnen sind früh auswerten und jene, welche Kosten verursachen erst spät. Der Informationsgehalt der verschiedenen Parameter muss natürlich mitberücksichtigt werden.

Ja, ich möchte beim Einlesen möglichst schnell auf Änderungen Prüfen, bzw. Vergleichen ob sich Lokale und Remote-Verzeichnisse geändert haben.
Danke für die Vorschläge mit den zusätzlichen Parametern, aber im Moment reichen mir die JA/NEIN Aussagen zu Files welche geändert wurden, völlig aus.
Zusätzlich dazu wäre dann noch entsprechend der letzte Zuugriff interessant, aber optional.

Weiterhin war mein Gedanke, dass diese Struktur dan auch gleich das Navigieren in den Dateien übernehmen kann.
Also eine Klasse für Verzeichnisstruktur mit Navigation und schneller Hash-Suche.

Womöglich ist aber auch eine Trennung beider "Concerns" sinnvoller, gefühlt würde ich momentan aber eher alles in eine Baumstruktur packen,
um nicht noch viel Redundanz und Komplexität beim Aufrufer reinzubekommen.
Ausserdem wäre eine zentrale Klasse sicher fehlertoleranter auszulegen als zwei separate, die sich überschneiden können.