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

[juergen]

sorry, wenn ich mich nicht richtig ausgedrückt habe...
Ich lese die Dateiinformationen erst einmal über TSearchRec.... ein.Danach die MP3- und Exif-Infos.
Die Frage ist in erster Linie wo ich die relativ große Menge der Dateiinformationen speichere (DB,TObjectList ????), so das auch eine Suche sehr schnell ist. Weiterhin was ich zur Darstellung der reinen Dateinamen verwende (Quantumgrid, ...???), bzw. alternative Konzepte

[DeddyH]

Ich denke, eine Datenbank kann nicht verkehrt sein. Wenn man dann noch entsprechende Indizes anlegt, sollte auch die Performance zufriedenstellend sein. Wie man die Daten darstellt, ist Geschmackssache.

[Popov]

Wie ich schon oben meinte, wenn es nur Suche sein soll, also DB kein Muss ist, würde ich es in einer Liste speichern. Egal welche es am Ende auch ist, ob Array oder TObjectList. Allerdings kann ich dir aus meiner Erfahrung sagen, dass TObjectList schnell genug ist. Ich hab letztens hier irgendwo ein kleines Beispiel mit TObjectList veröffentlicht, bei dem ich 100.000 Daten in etwa 14ms sortiert habe.

Und wie gesagt, ich würde aus TSearchRec nicht nur einzelne Informationen einlesen, sondern einfach alles kopieren. TSearchRec ist nur ein Record, mehr nicht. Man hat also gleich alles bei Hand.

[mm1256]

TSearchRec ist zum Speichern schon sehr effizient, keine Frage. Aber wenn du dann bei der Suche...

Zitat:

Es gilt oft ca. 500.000 Datensätze nach Dateinamen zu durchsuchen und zu filtern. Das Ganze muss unter 1 s ablaufen.

...die TSearchRec's wieder aufdröseln musst, gibt's die A-Karte gratis

[mkinzler]

Zitat:

Wie ich schon oben meinte, wenn es nur Suche sein soll, also DB kein Muss ist, würde ich es in einer Liste speichern. Egal welche es am Ende auch ist, ob Array oder TObjectList. Allerdings kann ich dir aus meiner Erfahrung sagen, dass TObjectList schnell genug ist.

Wenn es nur um diese Suche geht, kann man ganz auf die Speicherung in einer Liste o.ä. sparen, da man ja sowie so die Verzeichnisse durchsuchen muss. Sollen die Informationen persistent erhalten werden, muss man diese ja wieder irgendwie ablegen, wenn man nicht bei jedem Programmstart sen "index" neu anlegn lassen will. Ich würde die Infos gleich in einer datenbnk ablegen.

[Dejan Vu]

Deine Idee mit einer kleinen DB war schon mal nicht falsch bzw. der naheliegende Weg.

Erstelle Dir zunächst die Tabellenstruktur(en) zum Speichern der Daten in der DB. Das geht einher mit den Recherchemöglichkeiten, die Du deinem System spendieren möchtest.

Anschließend erzeugst Du die Queries, um deine Fragen zu beantworten.

Dann importierst Du die Daten und prüfst, ob deine Queries zum gewünschten Ergebnis in der gewünschten Zeit kommen.

Du änderst ggf. das Design so, das deine Performancevorgaben erfüllt werden.

Und zum Schluß die UI.

[stahli]

Die Ordnerstruktur ist ja letztlich auch eine Datenbank.
Unter VisualStudio kann man wohl auch per SqlServer direkt auf die Ordnerstruktur zugreifen. Genaueres kann ich dazu aber jetzt nicht sagen.

Welche Suchfunktionen Delphi in Ordnern ermöglicht, kann ich auch nicht sagen.

Eine Datenbank zu verwenden und diese zum Suchen zu verwenden ist sicher kein schlechter Weg.
Ein paar passende Indizes würde eine schnelle Suche ermöglichen.

Das Problem wird die Synchronisation sein. Wenn Du Dein Projekt startest und zum letzten Lauf hat sich etwas an in den Ordnern geändert müsste ja die Datenbank erst mal aktualisiert werden. Gleiches, wenn sich während der Laufzeit etwas in den Ordnern ändert.

Im Grunde hast Du einen redundanten Datenbestand.

Insofern wäre es vielleicht besser, die Ordner direkt nach Treffern zu durchsuchen und diese zur Anzeige in einer Liste zu sammeln.

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