Das ist schön. Und wie?
Für alle die, die hier irgendwie hergefunden haben und denen eine Antwort schuldig geblieben ist:
=> Ein guter Ansatz hat irgendeine Form von Datenbank im Backend. Dateisystem durchsuchen ist teuer, aber wenn man etwas sucht, dann möchte man das im Normalfall eher schnell haben. Wir haben also einen gewissen Interessenkonflikt.
Exakt "wie" die Datenbank aussieht ist egal.
Unixoide kennen locate(1). Das kann man da einfach verwenden und mit updatedb bzw ggfs. locate.updatedb aktuell halten, wenn die Betriebsumgebung das nicht schon für einen macht.
Unter Windows hilft es schon ungemein, wenn man einfach mittels zB DIR in der Kommandozeile - oder Get-ChildItem -Recurse in Powershell -- einfach eine Textdatei erstellt, in der alle Verzeichniseinträge aufgelistet sind. Ob und wie man die dann aktuell hält ist egal, aber erstmal möglich (cron, scheduled task).
Ein echtes DBMS im Backend ist natürlich "Königsdisziplin", wo man dann jeden Käse damit machen kann, der einem so vorschwebt... wenn man das will und wenn man einen spezifischen Nutzen davon hat.
Die Dateisuche skaliert dann mit der Anzahl der Dateien, nicht mit deren Größe: Je mehr Einträge in der Datenbank, desto länger dauert die Suche (aber immer noch
signifikant schneller als das Dateisystem durchforsten zu müssen).
Entsprechend hilft eine Sortierung beim Anlegen der Textdatei(en), eine vorsorgliche Organisation der Textdateien zB nach Laufwerksbuchstabe oder zB nach Spielen, Bildern, Filmen usw, damit man nicht unnütz viele Daten mit betrachten muß, die man grad gar nicht haben will.
Bei DBMS dagegen ist das zum Suchzeitpunkt egal, aber dafür hat man den Extraaufwand, den Datenbestand aus dem Dateisystem möglichst schmerzfrei in ein möglichst gut durchsuchbares Datenbankschema zu pressen.
