Hunderttausende Dateinamen mit Pfaden effizient in Datenbank speichern

[Benmik]

Danke für die schnellen Antworten.

Hansa: Jeder Verzeichnisname darf - wenn ich mich nicht irre - unter NTFS 256 Byte umfassen. Und wenn jemand will, kann er 20 Unterverzeichnisse verschachteln. Da ist man schnell bei ziemlichen Größen.

Puke: Ja, auf sowas bin ich auch gekommen. Hast du da vielleicht mal ein Codebeispiel? Und wie macht man das mit Dateivergleichen? Da muss man dann für jede einzelne Datei den Pfad zusammensetzen?

Benmik

[Perlsau]

Zitat von Benmik:

Jeder Verzeichnisname darf - wenn ich mich nicht irre - unter NTFS 256 Byte umfassen. Und wenn jemand will, kann er 20 Unterverzeichnisse verschachteln. Da ist man schnell bei ziemlichen Größen.

Offenbar hast du da was falsch verstanden. Wenn du selbst einmal Hand anlegen und versuchen würdest, einen Pfad zu erstellen, der größer ist als 232 Zeichen, würdest du ganz einfach feststellen: Es geht nicht.

Zitat von Benmik:

Und wie macht man das mit Dateivergleichen? Da muss man dann für jede einzelne Datei den Pfad zusammensetzen?

Nein, du kannst dir z.B. ein View erstellen, das einen Concat von Pfad und Dateiname beinhaltet. Ich erstelle Views gewöhnlich für alle Tabellen, in denen Spalten auf Detailtabellen verweisen.

[Benmik]

Wozu das Ganze?

Die Dateien in der DB sollen mit neuen Dateien verglichen werden, ob sie - also Pfad und Dateiname - schon vorhanden sind. Über TWin32FindData erfolgt dann die weitere Prüfung auf Identität.

Hashwert: Genau! Sind für alle Dateien in der DB vorhanden. Durch den Vergleich soll aber gerade die Berechnung von neuen Hashwerten eingespart werden.

Perlsau: Genau das habe ich auch schon realisiert (wenn ich mal davon ausgehe, dass ein View praktisch eine Abfrage ist). Ich hatte nur 2 Probleme:

1. Zum einen wird sehr viel Speicher verbraucht (unter XP sind oft nur 2 GB im Einsatz, mehr als 3,5 bei 32 Bit nicht drin)

2. Ich muss dann eventuell sehr lange Pfade vergleichen. Ein Index wird da sehr groß, oder? Ich würde gerne eine eindeutige ID für jede Datei vergeben (Cardinal) und die vergleichen. Ist für bestehende Dateien in der DB natürlich kein Problem, aber es gibt wohl keinen Weg, für eine neue Datei inklusive Pfad auf schnelle Weise zu der identischen ID zu kommen (wenn Name und Pfad gleich sind), oder?

[Benmik]

Vielleicht kann ich die Frage etwas kondensieren.

Ich habe in einem Pfad zu einer Datei z.B. 10 Verzeichnisse, die alle eine ID (Word) haben, also 10 maximal fünfstellige Zahlen.
Gibt es einen Algorithmus, der aus einer solchen Zahlenkombination - bei der auch die Reihenfolge stimmen müsste - eine eindeutige ID errechnen kann?

Wie wäre es, wenn ich die Zahlen hintereinander schriebe und daraus einen Hashwert (z.B. MD4) errechnen würde. Wäre das nicht eindeutig?
Wie machen die Profis sowas?

[Perlsau]

Zitat von Benmik:

Die Dateien in der DB sollen mit neuen Dateien verglichen werden, ob sie - also Pfad und Dateiname - schon vorhanden sind. Über TWin32FindData erfolgt dann die weitere Prüfung auf Identität.

Wenn du, wie du schreibst, auf Vorhandensein einer Datei in einem bestimmten Verzeichnis prüfen willst, wozu benötigst du dann eine Datenbank? If FileExists then liefert dir doch bereits diese Information.

Zitat von Benmik:

Hashwert: Genau! Sind für alle Dateien in der DB vorhanden. Durch den Vergleich soll aber gerade die Berechnung von neuen Hashwerten eingespart werden.

Das verstehe ich jetzt nicht: Wie willst du einen Hashwert finden, wenn du gar nicht weißt, welchen Hashwert du suchst? Das erfährst du doch erst, wenn du aus einem Dateinamen (incl. Pfad) einen Hashwert berechnest. Gibt's den berechnete Hash bereits in der Datenbank, ist die Datei vorhanden, da aus derselben Pfad-Datei-Angabe immer auch derselbe Hashwert berechnet wird, wenn du stets dieselbe Berechnungsmethode anwendest.

Zitat von Benmik:

Perlsau: Genau das habe ich auch schon realisiert (wenn ich mal davon ausgehe, dass ein View praktisch eine Abfrage ist).

Ein View ist eine virtuelle Tabelle, die in der DB sozusagen ein fest verdrahtetes Select-Ergebnis darstellt. Du kannst ein View wie eine normale Tabelle auslesen. Darin steht dann nicht mehr nur die Id 15, sondern z.B: "C:\Temp\Test\". Wie du mit deinem DBMS ein View erstellst, sollte in der Dokumentation stehen.

Zitat von Benmik:

1. Zum einen wird sehr viel Speicher verbraucht (unter XP sind oft nur 2 GB im Einsatz, mehr als 3,5 bei 32 Bit nicht drin)

Wofür wird sehr viel Speicher verbraucht?

Zitat von Benmik:

2. Ich muss dann eventuell sehr lange Pfade vergleichen. Ein Index wird da sehr groß, oder? Ich würde gerne eine eindeutige ID für jede Datei vergeben (Cardinal) und die vergleichen. Ist für bestehende Dateien in der DB natürlich kein Problem, aber es gibt wohl keinen Weg, für eine neue Datei inklusive Pfad auf schnelle Weise zu der identischen ID zu kommen (wenn Name und Pfad gleich sind), oder?

Was heißt "sehr lange Pfade"? Ich hatte vorhin mal getestet und konnte in einem Ordner mit Namen "0123456789" 31 Verschachtelungen mit demselben Namen erstellen, dann war Schluß. Mehr als 256 Byte stehen da wohl nicht zur Verfügung. Doch wie bereits empfohlen: Teste es selbst aus, dann weißt du, was du hast.

Inwieweit soll dir eine eindeutige ID dabei helfen, zu überprüfen, ob eine gegebene Datei incl. Pfad bereits eingetragen ist? Es sei denn, du verwendest keine automatisch erstellten Id, sondern einen Hash, den du aus Datei und Pfad erzeugst und als Primary Key festlegst. Aber hier mußt du natürlich aus dem gesuchten Dateinamen erstmal einen Hashwert erzeugen, um danach suchen zu lassen.

Zitat von Benmik:

Ich habe in einem Pfad zu einer Datei z.B. 10 Verzeichnisse, die alle eine ID (Word) haben, also 10 maximal fünfstellige Zahlen.
Gibt es einen Algorithmus, der aus einer solchen Zahlenkombination - bei der auch die Reihenfolge stimmen müsste - eine eindeutige ID errechnen kann?

Glaubst du, diese Id wäre nicht eindeutig? Hast du bereits überprüft, ob bei verschiedenen Dateien in verschiedenen Ordnern dieselben Ids vergeben werden? Was sind das für Ids? Woher stammen diese Werte?

Zitat von Benmik:

Wie wäre es, wenn ich die Zahlen hintereinander schriebe und daraus einen Hashwert (z.B. MD4) errechnen würde. Wäre das nicht eindeutig?

Wenn du aus einem vollständigen Dateinamen einen Hashwert erzeugst, ist der eindeutig, weil in einem Ordner niemals zwei Dateien mit demselben Namen stehen können.

Zitat von Benmik:

Wie machen die Profis sowas?

Keine Ahnung. Was ist ein Profi? Jemand, der das beruflich macht? Oder jemand, der eine ähnliche Aufgabe bereits gelöst hat?

[hoika]

Hallo,

bei einer richtigen DB (z.B. Firebird) gibt es kein RAM-Problem.
Die Dateinamen / Indizes sind eh schon komprimiert.

Was willst du denn verwenden ?

Heiko

[Furtbichler]

Ich verstehe die ganze Problematik nicht. Ich habe eine Liste von eindeutigen Dateinamen. Wie die im Detail aussehen, ist doch zunächst vollkommen egal.

Nun möchte ich wissen, ob sich die Datei verändert hat, um sie ggf. neu zu sichern. Da bietet sich zunächst das Archivbit an (Größe und Änderungsdatum vielleicht noch). Ein Hash... ich weiß nicht, ob es sinnvoll ist, Bestrebungen des Anwenders zu umgehen, eine Datei zu ändern, ohne das Archivbit zu setzen. Soweit ich weiß, wird das bei jeder Änderung gesetzt. Weiterhin ist das eine sehr einfache Möglichkeit, Dateien vom Archivieren auszuschließen (einfach nicht setzen bzw. zurücksetzen).

Aber gut, auch zweitrangig, wie man Änderungen feststellt. Es geht ja hier um die Frage, wie man so eine Dateiliste in einer Datenbank ablegt. Natürlich ist hier auch entscheidend, was mit der Liste angestellt werden soll, d.h. die Speicherstrategie richtet sich nach den Retrievalanforderungen.
In den meisten Fällen wird eine einfache Liste, d.h. Tabelle, am schnellsten umzusetzen und für die meisten Use Cases geeignet sein.
Allerdings kann ich mir bei einem richtig guten Backupprogramm auch vorstellen, das es Umbenennungen von Verzeichnissen und Dateien mitbekommt und seine eigene Liste entsprechend überarbeitet. Wenn man das umsetzen will und (!) wirklich sehr viele Dateien hat(> 1Mio), dann wäre ein anderes Speichermodel vielleicht sinnvoll(naheliegend: Baum). Ansonsten ist die banale Liste wirklich keine Hürde. Die Suche (auch nach Verzeichnissen) kann immer einen Index verwenden, denn man vergleicht ja den Anfang (also ein "LIKE 'FOO%'"). Mal eben 1000 Dateien umzubenennen ist nun auch keine Hürde.
Um ehrlich zu sein, würde ich noch nicht einmal eine Datenbank nehmen. Die Rechnung sieht so aus:
Maximale Anzahl der Dateien, die supported werden: 1 Mio (Beispiel)
Maximale Länge eines Dateinamens : 255 Bytes.
Benötigter Speicher dafür: 256 MB.
Wo war jetzt gleich das Problem?

Benötigst Du allerdings 100 Mio Dateien, dann solltest Du dir eine DB anschaffen, das ist logisch.

Zitat von hoika:

Die Dateinamen / Indizes sind eh schon komprimiert.

Aber nur RLE, was hier überhaupt nichts bringt.

[Puke]

Bin eher Theoretiker ...
Da ich nicht weiß wie du deine datenbankzugriffe organisierst, mach ich dir mal diesen Vorschlag:

Pfade zusammensetzen ( muss auf Datenbanken umgestellt werden! sry):

Delphi-Quellcode:

// Im loc_Datensatz stehen die Dateipfad-Nummern
Result  := loc_Datensatz.device; // Festplatte oder sonstwas
For loc_i_counter := 0 to loc_Datensatz.AnzahlOrdnerTeile do
  // FTabellePfade sind die Dateipfade
  Result := Result + FTabellePfade.gebepfadNummer(loc_datensatz.Pafdnummer(loc_i_counter));
End;
Result := Result + loc_Datensatz.Dateiname;

Bei Vergleich fehlt mir jetzt das Wissen wofür?
Im Prinzip kannst du zwei Datensätze nehmen und dann Nummer für Nummer miteinandervergleichen. hurra wir lieben Schleifen ...
Vorteil es bleibt linear! ( bei Strings nicht ganz so gegeben )

Gruß
Puke