Konzeptfrage: Datenhaltung vieler Datei-Infos und deren Darstellg mit schneller Suche

[jobo]

Die Frage von mkinzler halte ich für durchaus wichtig.
Wie soll das Programm sich bei Änderungen im Dateisystem verhalten?
Jede Persistierung egal wie sie erfolgt entfernt sich zwangsläufig von der Realität im Dateisystem. Eine suche in den persistierten Daten findet demnach entweder Leichen oder "übersieht" Neueinträge.
Ob eine DB Persistierung den erfofften Geschwindigkeitsvorteil gegenüber einer Dateisystemsuche erbringt und der Aufwand dazu im Verhältnis steht, wäre eine Frage, die man näherungsweise mit kleinem Aufwand anhand von Testdaten prüfen könnte.

Hübsch wäre vielleicht, sich in die Änderungen des FS zu hooken und so die Persistierung on the fly synchron zu halten.

[Sir Rufo]

Man kann das Programm doch mit der Suche im Explorer vergleichen. Die indizierten Orte (Ordner) werden auch laufend überwacht (bzw. per Benachrichtigung bei einer Änderung).

Die einzige Frage ist, ob diese Indizierung permanent erfolgen soll (Dienst) oder nur wenn die Anwendung läuft.

[mm1256]

Zitat von jobo:

Die Frage von mkinzler halte ich für durchaus wichtig.
Wie soll das Programm sich bei Änderungen im Dateisystem verhalten?

Ja, das ist wichtig. Weil es wohl hier um so was ähnliches wie bei meiner privaten mp3-Verwaltung geht, schreib ich mal, wie ich das hier gelöst habe: In einer Config-Datei speichere ich beim Anlegen neuer Dateien die jeweiligen Pfade. Bei einer Aktualisierung gehe ich (mittlerweile in einem eigenen Thread) diese Pfade durch und schaue nach, ob eine Datei verändert wurde. Die Änderungen werden im Hintergrund ohne die Anzeige zu stören über eine separate TTable-Komponente in die DB geschrieben. Für die Anzeige verwende ich eine TQuery. Somit reicht ein "Refresh" der TQuery wenn die Aktualisierung fertig ist, um diese auch auf den Bildschirm zu bringen. Man bekommt also von der Aktualisierung gar nichts mit.

In der DB selber werden nur die Dateinamen gespeichert. Diese sind generell so aufgebaut: {Interpret} - {Titel}.mp3. Ein kleines Tool ermöglicht das physikalische Umbenennen vorhandener mp3-Dateien (Interpret+Titel eingeben, und dann Datei umbenennen). Das Datei-Datum wird mit dem Erscheinungsdatum oder Aufnahmedatum belegt. Die Zeit ist bei erfassten Dateien immer 00:00:00. So sieht man auch im Explorer neue/veränderte Dateien. Interpret, Titel, Datum/Zeit, Erscheinungsjahr, Land, Genre, Rhytmus und Dateiname sind indizierte Felder. Interpreten, Land, Genre und Rhytmus werden wegen einheitlicher Schreibweise über LookUp's aus entsprechenden DB's gefüllt. Somit ist die Suche und das Filtern (z.B. nur ein Interpret) von Daten sehr schnell.

Vielleicht hilft's ja?

[Popov]

Für mich ist die Frage die sich stellt die: sollen die Infos für die Nachwelt gesichert werden? Denn dafür wäre eine Datenbank durchaus geeignet. Eine Bank ist immer dann gut, wenn man etwas für eine gewisse Zeit da ablegen will, z. B. Geld auf Bank bringen oder Adressen in einer Datenbank ablegen. Oder geht es hier nur um das Einlesen von Informationen zwecks temporärer Verarbeitung?

[Sir Rufo]

@Popov

Es geht hier rein um die Performance und die Datenbank soll als Cache herhalten.

[juergen]

Hallo zusammen,

einleitend zuerst mal das Anwendungsgebiet des Tools, dann wird wohl einiges klarer:
- Im geschäftl. Bereich dient es dazu jede Woche einmal ein Serverlaufwerk mit ganz vielen Dateien neu einzulesen.
Dann, z.B. während eines Kunden-Telefonats, kann ich *schnell* mit meinem Tool irgendein Dokument suchen und direkt aus der Suchvorschau öffnen. Ggf. muss ich die Suche ständig wiederholen, bis das gewünschte Dokument gefunden wurde! Mein Gegenüber wartet... Auf Grund der Datenmenge (ca. 500.000 Dateien) ist die Performance eben wichtig.
- Im privatem Bereich dient das Tool vorwiegend zum Einlesen von MP3-Dateien und Fotos, der Suche nach Liedern, wo die genaue Schreibweise nicht immer 100% bekannt ist (verschiedene Such-Algorithmen) und die Bearbeitung der Dateien (Stapelbearbeitungen zum taggen oder umbenennen...). Weiterhin kann das Ergebnis der Suchvorschau direkt an meinen Musikplayer übergeben werden um z.B. eine Playliste zu erstellen...

Die Dateiinformationen müssen *nicht* permanent neu eingelesen werden (zumindest im Moment).

Ich hatte heute nun mal begonnen mit einer SQLite-DB etwas zu experimentieren. Dazu habe ich ca. 140.000 Dateipfade+Dateinamen in eine DB mit nur einer Tabelle gepumpt. Die Tabelle hat nur 2 Felder => AutoInc (Integer) und Dateipfad (255 VarChar). Nun, ich bin erst mal ernüchtert was die Suchgeschwindigkeit angeht.
Weiterhin hatte ich zum testen mal mit SQLite Maestro-Programm gespielt. Das Suchen dauerte dort auf jeden Fall länger wie meine momentane Suche in einer TStringList! Allerdings weiß ich nicht wie die Suche dort funktioniert. Das Maestro-Programm nutzt wohl auch das Quantumgrid zur Anzeige. Ob jetzt das Grid die Daten filtert oder eine Query weiß ich nicht.
Ich habe gelesen, dass evtl. InMenory-Lösungen hierfür hilfreich wären.

Insgesamt habe ich einfach keinerlei Erfahrung in dem Bereich und daher kostet alles viel Zeit.
Da der Aufwand für mich im Moment überhaupt nicht einschätzbar ist (wer weiß was mich bei Nutzung einer DB noch alles so erwartet), werde ich wohl eher das mir fehlende Datei-Datum zusätzlich in meiner TStringList irgendwie speichern.

[mkinzler]

Nach was suchst Du? hat das Feld einen Index?

[Luckie]

Würde es nicht reichen sich zu merken wo die Datei ist und dann, wenn man sie braucht, die Infos auszulesen?

Was du jetzt vor hast klingt für mich, was Microsoft mal geplant hatte, das Dateisystem in eine DB zu überführen. Sie haben es aber nie verwirklicht.

Weil das Problem ist doch letztendlich die Datei schnell zu finden. Die Infos auslesen dauert doch wohl nur Millisekunden. Also würde ich den Dateinamen und den Speicherort in der DB ablegen und den Dateinamen indexieren. Wenn es mehrere gleichnamige Dateien gibt, kann man sie am Speicherort identifizieren.

[mkinzler]

Zitat:

Was du jetzt vor hast klingt für mich, was Microsoft mal geplant hatte, das Dateisystem in eine DB zu überführen.

Wie kommst Du darauf, er legt ja nur die Pfade ab, nicht den Inhalt.

[idefix2]

Wenn ich das richtig verstehe, geht es dir nicht um eine schnelle gezielte Dateisuche, sondern um einen rasch reagierenden Dateifilter, der aber meistens die komplette Tabelle durchsuchen muss, weil der gesuchte Namensteil nicht unbedingt am Anfang des Dateinamens steht.

In so einem Fall ist eine in-Memory Lösung wie zum Beispiel eine Stringliste sicher schneller als jede Datenbank.

Abhängig davon, wie so ein Dateifilter bei dir genau aussehen kann, sind aber sicher Optimierungen möglich, um das zu beschleunigen.