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

[jobo]

Zitat von juergen:

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.

Also ich hab hier ein Lazarusprogramm, das unter der Sekunde bleibt bei ca 550000 Datenätzen. Das ist aber nicht optimiert auf sowas.