Hunderttausende Dateinamen mit Pfaden effizient in Datenbank speichern

[Benmik]

Ich muss mehrere Hunderttausend Dateinamen mit den zugehörigen Pfaden in einer Datenbank speichern. Die Verzeichnisnamen blähen die Datenbank natürlich gewaltig auf. Ich habe mir schon selbst ein System gebastelt, in dem jeder einzelne Verzeichnisname eine ID bekommt und die Pfade zusammengesetzt werden. Das funktioniert auch, aber leider lassen sich nun die Dateien inklusive Pfade nur noch umständlich vergleichen.

Für sowas muss es doch schon eine Lösung geben.

[Hansa]

Wo liegt denn das Problem ? An 2 Byte oder was ? Sagen wir 1 Mio. Dateinamen mit Pfadlängen von 200 Zeichen (geht nicht nur max. 128 ? ), das wären 200 MB. Nicht viel mehr als Peanuts für DB. Und das geht sogar noch locker auf CD. Oder zig-fach auf USB-Stick für 5 EUR.

[Puke]

Zahlen sind doch dreimal besser zu vergleichen als Strings?
Nur den Dateinamen würde ich als String zu jedem Record speichern. Für ordnerstrukturen relationen mit schlüsseln!

[Puke]

@Hansa: Hilfe nein! Stell dir vor du willst einen Ordnernamen umbenennen... Bei deiner Lösung musst du 100000 mal überprüfen und ändern. Bei mir brauchst du nur einmal die Relations-Tabelle durchgehen und einmal ändern....

[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.

[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

[michaelthuma]

Schwierige Übung. Versuche die Bitmuster der Pfade zu komprimieren und in einem Index abzulegen ohne DB.

Warum willst du den Pfad vergleichen? Sucht du Duplikate?

Zitat von Benmik:

Ich muss mehrere Hunderttausend Dateinamen mit den zugehörigen Pfaden in einer Datenbank speichern. Die Verzeichnisnamen blähen die Datenbank natürlich gewaltig auf. Ich habe mir schon selbst ein System gebastelt, in dem jeder einzelne Verzeichnisname eine ID bekommt und die Pfade zusammengesetzt werden. Das funktioniert auch, aber leider lassen sich nun die Dateien inklusive Pfade nur noch umständlich vergleichen.

Für sowas muss es doch schon eine Lösung geben.

[mjustin]

Zur Beschleunigung der Vergleiche bietet sich der Einsatz eines Hashwertes an...

[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?