Vielen Dank für die ausführliche Antwort. In meinem IT-unerfahrenen Hirn spukte halt der Gedanke: Wenn ich eine Abfrage auf alle Titel mache, geht das ja problemlos: Alle Titel werden angefaßt und ins Fenster geschrieben. Wenn ich jetzt dasselbe mache, aber nur die ins Fenster schreibe, die dabei länger als dreidreißig sind, erscheint mir das nicht so kompliziert.
Denke ich.
Ich.
Das wäre das besagte “Filtern im RAM”, also erstmal die ganze Liste laden, und die nicht passenden Titel ausblenden. Aber wie lange das Laden der Gesamtliste dauert, siehst du ja, wenn du links im Baum auf “Alles” klickst. Und wir haben Kunden mit teilweise sehr großen Bibliotheken (100.000 und mehr Einträge).
Da ist es sinnvoll, auf die Filter-Funktionen von SQL zurückzugreifen, so dass von vornherein nur die passenden Titel ausgespuckt werden. Aber dazu muss “unsere” Anfragesprache eben in SQL übersetzt werden.
Auch von mir ein Dank für die Hintergrundinformationen.
Ich bin ja nur Datenbank-Anwender und habe mir das auch einfacher vorgestellt. Schon bei meiner ersten Tonträger-DB (F&A für DOS v. Symantec) konnte man (Mitte der 80er) mehrere Filterkriterien anwenden. Daher kommt wohl meine naive Ansicht, dass so etwas grundlegende DB-Funktionen sind.
Kann ich bestätigen. Ich habe aktuell 190.079 Einträge. Anzeigedauer für alles ca. 55 Sekunden - wenn die Datenbank frisch “Vacuumiert” ist.
Grundsätzlich sind es die, ja. Die Herausforderung besteht immer darin, das, was der Mensch (User) möchte, in die Sprache des Computers zu übersetzen. Das fängt bei den GUI-Dialogen an und endet dort, wo man es in die entsprechenden SQL-Anfragen übersetzt hat.
Und unser (schönes) System mit den frei definierbaren Attributen macht es wirklich kompliziert.
Deine alte Datenbank aus den 80ern hatte vermutlich feste Spalten wie Interpret, Titel, Jahr, Genre, etc.
In der mAirListDB stehen nur die Stammdaten (ID, Titel, Interpret, Länge, etc.) in der Haupttabelle items - die anderen Felder, eben was du auf dem Reiter Attribute erfasst, stehen in einer zusätzlichen Tabelle item_attributes, und zwar jeweils als Tupel (Titel-ID, Attribut-Name, Attribut-Wert).
Bei Suchanfragen muss man diese Tabellen dann miteinander verknüpfen - Fachjargon: JOIN - und zwar im Zweifel auch mehrfach. Das macht die SQL-Anfragen sehr komplex.
Wie gesagt, alles theoretisch möglich, aber erfordert Zeit, die nicht immer vorhanden ist.
Off-topic: Konntest du in der v7 bemerken, dass sich die Ladezeiten verkürzt haben? Sollten sie.
Aha. Sehr einleuchtend.
Ja, ich habe etwas schnellere Ladezeiten bemerkt. Kann sie aber nicht genau beziffern. Eben gerade mit dem aktuellen Datenbestand gemessen waren es immerhin zehn Sekunden weniger.