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

[juergen]

Hallo zusammen,
dieser Thread ist aus diesem entstandehttp://www.delphipraxis.net/1307584-post1.htmln:

Da ich nun motiviert bin ein altes Programm neu hochzuziehen, möchte ich jetzt auch "auf das richtige Pferd" setzen.

Voraussetzungen: Delphi XE, ich habe das Quantumgrid und für DB-Zugriffe den Vorgänger vom FireDAC (AnyDAC).
Da ich diese Komponenten schon etwas kenne, würde ich diese auch am liebsten nutzen wollen, den VT eher nicht (momentan zu kompliziert für mich, da ich noch nie damit gearbeitet habe).

Mein momentan überlegtes Konzept:
Welche Daten benötige ich überhaupt? => Dateipfad, Dateiname, Änderungsdatum, evtl. Erstelldatum, Dateigröße. Weiterhin in einem separaten Thread einige MP3- und Exif-Infos auslesen.
Mein momentaner Plan: Ich sauge mir das Ganze in eine SQLite-DB!??? Mehrplatzfähigkeit wird nicht benötigt.

Was wichtig ist:
Performante Datei-Suche. Es gilt oft ca. 500.000 Datensätze nach Dateinamen zu durchsuchen und zu filtern. Das Ganze muss unter 1 s ablaufen.
Da weiß ich nicht ob die o.g. Komponenten das überhaupt her geben.
Weiterhin ist wichtig, dass das Ganze in irgendeiner Form abgespeichert werden kann. Das Programm soll beim Neustart alle zuvor eingelesen Datei-Infos anzeigen und nicht neu einlesen müssen.

Meine Fragen:
1. Welche Erfahrungen habt ihr in diesem Bereich und welche Empfehlungen resultiert daraus?
2. Welches Konzept würdet Ihr anwenden? Datenhaltung= DB?, Anzeige= Quantumgrid?
3. Ist eine Datenbank das Mittel der Wahl? (performant genug?) Evtl. TObjectList?
4. Verwendung welcher Komponenten?

Vielen Dank schon mal vorab!

[idefix2]

Aus deinem Beitrag ist mir nicht wirklich klar geworden, was du überhaupt genau machen willst.

[Popov]

Ich weiß zwar auch nicht was du speicherst (liest sich nach Daten, MP3, usw.). Wenn ich die Dateninformationen eines Verzeichnisses einlese, dann speichere ich alle Informationen zu einer Datei einfach als TSearchRec. Einfache geht es nicht und alle Daten sind später bei Hand.

TSearchRec in DB ablegen ist allerdings schwieriger. Trotzdem würde ich alles sichern.

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