Hier noch ein Beispiel, das mir Rätsel aufgibt:
Gesucht wird Yesterday Man von Chris Andrews.
Eingabe “Yesterday” => Treffer
Eingabe “Yesterday Man” => kein Treffer
Eingabe “Yesterday Andrews” => Treffer
Eingabe “Yesterday Man Andrews” => kein Treffer
Eingabe “Yesterday Chris Andrews” => Treffer
Kann ich mir nicht erklären?!?
Moin, benutzt Du eine Postgres-Datenbank oder die emulierte Abfrage?
Bei der Datenmenge von 250TSD Titel wäre eine “echte” PG-Datenbank zumindest durchaus sinnvoll und dann würde die Suche auch viel schneller Ergebnisse zurückmelden.
Es ist ja eigentlich nur je ein Klick mehr auf die Lupe und die Auswahl “Advanced Search”, dann öffnet sich sofort die Eingabemaske, in der Du gezielt nach Interpret, Titel etc. suchen kannst und mAirList dann ausschließlich in diesen Feldern sucht.
Ich werde Torben mal vorschlagen, dass der Suchbegriff in mit Anführungszeichen die Suche auf diese komplette Wortkette beschränkt (so wie das ja auch bei google etc. klappt). Das funktioniert momentan leider nicht und wäre ja eine gute schnelle Option
Ich benutze die mL-Datenbank. Volltextsuche ist deaktiviert
Hatte ich schon auf Anraten von Torben mit einer Pro-Testversion getestet, war nicht signifikant schneller. Und in v8.0 geht die Suche mit dem Standard-Suchfeld und entsprechenden Optionen ja sehr schnell (auch ohne Anführungszeichen!).
So kann man es natürlich auch sehen 
Ich dachte nur, für die Betaversion seien noch Ideen aus der Praxis willkommen.
Und welche Erklärung könnte es für diese Ergebnisse geben?
Zu den Smart Folders: Akribisch gepflegte Metadaten vorausgesetzt machen die im Scheduler eine hervorragende Figur! 
Ich hoffe ich hab’s richtig verstanden: Wenn der Scheduler neue Playlisten generiert, öffnet er den Smart Folder und somit aktualisiert sich auch der Inhalt dann für ihn, richtig?
Der Mechanismus ist relativ einfach:
In den Eigenschaften des Ordners ist eine Suchanfrage hinterlegt. Das macht ihn zum “Intelligenten Ordner”.
Wenn nun die Liste der im Ordner befindlichen Elemente abgerufen wird, erkennt das Backend, dass es sich um einen intelligenten Ordner handelt, führt die Suchanfrage aus und liefert die Ergebnisse als Ordnerinhalt zurück.
Es muss also nichts aktualisiert werden oder dergleichen, sondern das passiert komplett automatisch und in Echtzeit, jedesmal, wenn der Ordnerinhalt abgerufen wird. Egal ob vom Benutzer in der Ansicht, oder vom Scheduler während der Planung.
Ich kann mir noch ein paar schöne Erweiterungen für die Zukunft vorstellen, aber für den Moment bin ich ganz zufrieden damit, wie das funktioniert.
Einziges Problem in der ersten Beta (Build 6100) ist, dass die Ordner-Einstellungen für jede Station einzeln gespeichert werden (für diejenigen unter euch, die mehrere Stationen aus einer DB planen). Das ist natürlich im Regelfall nicht das, was man möchte. Im nächsten Build wird es dahingehend geändert, dass die den intelligenten Ordner betreffenden Eigenschaften automatisch auf alle Stationen repliziert werden, egal aus welcher heraus man sie bearbeitet.
Das sehe ich auch so. Demnach kommen weiter oben vorgeschlagene Zusätze ggf. erst in fernerer Zukunft?
Was ich aber gerne jetzt schon verstehen würde:
warum kommt es im Standardsuchfeld (also “gesamte Datenbank dursuchen”) zu folgenden für mich unerklärlichen Ergebnissen?
Ich hole mal etwas weiter aus, damit ihr versteht, was die 8.1 anders macht als frühere Versionen, und wo die Vorteile - aber auch Herausforderungen - liegen.
Zunächst muss man verstehen, wie die Suche in SQL-Datenbanken geschieht. Nämlich über den LIKE-Operator in Verbindung mit dem %-Zeichen als Wildcard
Beispiel: Diese Anfrage findet alle Elemente, deren Titel mit “Yesterday” beginnt.
SELECT * FROM items WHERE title LIKE 'Yesterday%';
Wohingegen diese Anfrage alle Elemente findet, die “Yesterday” irgendwo im Titel haben:
SELECT * FROM items WHERE title LIKE '%Yesterday%';
(Das % ist quasi das *, das ihr aus Dateisystemen kennt.)
Technisch gibt es einen riesengroßen Unterschied zwischen diesen beiden Anfragen. Denn die wichtigen Spalten sind in der mAirListDB alle indiziert, das heißt, die Datenbank pflegt einen alphabetischen Index, welche Datensätze welchen Wert enthalten.
Der ganz sehr effizient eingesetzt werden, wenn man entweder nach dem genauen Begriff sucht (title='Yesterday Man') oder nach Datensätzen, bei denen der Begriff am Anfang steht (title LIKE 'Yesterday%'). Da muss die Datenbank nämlich einfach nur im Suchindex bei Y nachschlagen, um es vereinfacht auszudrücken.
Sucht man hingegen mit LIKE '%Yesterday%' - also mit dem Suchstring an einer beliebigen Stelle innerhalb des Feldes - dann muss die Datenbank tatsächlich alle Datensätze einzeln durchgehen und den Inhalt des jeweiligen Feldes durchsuchen, was bei 250k Datensätzen durchaus dauern kann.
Bis mAirList 8.0 gab es im Dropdown-Menü, in dem man auch die zu durchsuchenden Felder auswählen kann, daher einen Haken Volltextsuche, um dieses Verhalten ein- oder auszuschalten.
Darüber hinaus gab es noch einen zweiten Haken Erweiterte Suche. Wenn dieser aktiviert war, wurden Suchanfragen, die aus mehr als einem Wort bestehen, intern zunächst getrennt gesucht, und dann die Schnittmenge der Ergebnisse zurückgeliefert. So konnte man z.B. nach Titel und Interpret gleichzeitig suchen.
Solange man sich in klassischen SQL-Datenbanken bewegt, kommt man aus diesem Korsett nicht heraus: Entweder sucht man nur (schnell) nach Begriffen am Anfang der Felder, oder man sucht (langsam) nach Begriffen, die auch in der Mitte von Feldern stehen können.
Das steht leider etwas im Widerspruch zu dem, was wir Nutzer heutzutage erwarten und von Suchmaschinen wie Google gewohnt sind: Man gibt einen Haufen Begriffe ein, und erhält sehr schnell genau die Treffer, die zu diesen Begriffen passen.
Das funktioniert bei Google aber nur deshalb, weil die einen Volltext-Index für die Suchergebnisse erstellen, also quasi jede Webseite in ihre einzelnen Wörter zerlegen, und diese in einer effiziet zu durchsuchenden Tabelle speichern.
Der SQL-Standard sieht soetwas nicht vor. Gleichwohl existiert das mittlerweile bei manchen SQL-Typen als proprietäre Erweiterung. Und genau solch eine, nämlich die von PostgreSQL, unterstützt mAirList 8.1 nun: PostgreSQL: Documentation: 18: Chapter 12. Full Text Search
Aus Entwicklersicht ist das sehr komfortabel, denn man muss nur einmal die entsprechenden Indexe anlegen (und die Trigger, die den Index bei Änderungen an Elementen automatisch aktualisieren), und danach kann man die Suchanfrage einfach so in die Datenbank werfen, und kriegt sehr schnell die passenden Ergebnisse zurück.
Andere Datenbanken können sowas zum Tel auch, da muss ich aber noch schauen, inwieweit das für unsere Zwecke geeignet ist.
Was passiert nun, wenn man kein PostgreSQL mit aktiviertem FTS benutzt? Dafür sind die beiden anderen Modi da, die so ähnlich arbeiten wie mAirList 8.0 - verglichen mit dessen alten Checkboxen:
Ich hatte gehofft, dass diese beiden Auswahlmöglichkeiten ausreichen, um die echte Volltextsuche nachzubilden. Entnehme aber euren Rückmeldungen, dass eventuell noch Finetuning-Optionen notwendig sind, insbesondere bei sehr großen Datenbeständen.
Was ich mich frage: Ist es überhaupt notwendig, dass bei der einfachen Suche mehr Felder durchsucht werden also Interpret und Titel (und ggf. Datenbank-ID und Externe ID)? Könnte man sich auf den Standpunkt zurückziehen, wer in Attributen oder nach bestimmten Titellängen suchen möchte, möge die erweiterte Suche verwenden? Das würde schonmal alles etwas beschleunigen, denke ich.
Und um das hier noch aufzuklären:
Im Modus “deaktiviert” werden nur Datensätze gefunden, bei denen der Suchbegriff am Anfang des Feldes steht. Dennoch werden die einzelnen Wörter der Suche nach Leerzeichen getrennt und separat gesucht.
Suchst du also zum Beispiel nach “Yesterday Man”, dann findet er nichts, weil das “Man” nicht am Anfang des Titelfeldes steht.
Als mögliche Lösung könnte man der Datenbank sagen, finde auch Einträge, bei denen der gesamte Suchbegriff (incl. Leerzeichen) am Anfang des Feldes steht. Dann würde er “Yesterday Man” finden.
Schwieriger wird es, wenn du drei Wörter eingibst, da dann nicht sofort klar ist, welche Teilmengen jetzt zueinander gehören.
Hinweis an der Stelle: Die Möglichkeit, mit Anführungszeichen zu arbeiten, kommt im nächsten Snapshot.
Vielen Dank für die interessanten und ausführlichen Hintergrundinformationen.
Das unterstütze ich ausdrücklich.
Man könnte die einfache Suche dann als Schnellsuchfeld z.B. im Livebetrieb nutzen. Dafür würden Titel und Interpret (Externe ID wäre mir auch nützlich 
) vollkommen ausreichen. Die gleichzeitige Suche von Titel und Interpret halte ich dort für verzichtbar.
Das fände ich schon ganz hilfreich.
Suche mal nur mit dem ersten Wort “I Feel Love” o.ä. wenn Du keinen Interpreten weißt 
Aber vielleicht ist die Volltextsuche mit der Beschränkung auf die o.g. vier Felder dann ja auch wieder schnell genug.
Meine private “Challenge” bei der Schnellsuche ist es, mit möglichst wenig Eingabe den richtigen Titel zu finden. Dazu war bis 8.0 die Einstellung “Volltextsuche an” und “Erweiterte Suche aus” ausreichend schnell. Für “Have You Ever Seen The Rain” führte dann z.B. auch “er seen t” zum Ziel. Mit der Feldanfangsuche müsste ich mindestens “have you ever s” eingeben.
Du bist ein Fuchs…
Ich habe gerade einen Build 6102 hochgeladen. Noch nicht wirklich intensiv getestet, aber dafür habe ich ja euch
Snapshot - Build 6102
[+] DB: Support for phrase search (double quotes) in disabled/emulated FTS mode
[+] DB: Smart Folder configuration is populated across all configured stations
[+] Advanced Search: Added more fields
[+] Advanced Search: Added Reset button
[+] DB: Non-native full text search modes renamed to "Fast" and "Full",
optimized algorithms, only Artist, Title, Database ID and External ID
fields are being searched
Feedback zu den Suchfunktionen bitte gerne weiter hier im Thread!
Schnelles FB: Der Scrollbalken bei den Einstellungen der Smart Folders funktioniert nur durch Ziehen des Balkens, das Scrollrad hat zumindest bei mir keine Funktion.
Du meinst im unteren Bereich bei den Attributen?
Das war in der ersten Version auch schon so. Und ist ja auch im Eigenschaftenfenster schon immer so gewesen.
Ja. Habe ich vorher nicht gesehen, weil ich nicht soviel Attribute hatte.
Demzufolge schließe ich mich @calypso60 an. 
Hab den fehlenden Haken gefunden, wird behoben.
Würde das dann auch im Eigenschaftenfenster funktionieren?
Mein erster Test zeigt:
Die Schnellsuche ist prima. Um beim “Yesterday Man” zu bleiben findet man jetzt im Modus “Vollständig” den Datensatz auch wieder mit “rday ma” oder “man andrews” in rasanter Zeit - TOP!
Fehler: Im Feld “Elementtypen” kann man nichts eingeben.
Noch eine Frage: Könnte die letzte Position des Dialogs “Erweiterte Suche” gespeichert werden? Sie erscheint nach Neustart immer “über” der Datenbank und muss verschoben werden.
Sorry, mein Fehler. Habe die Auswahlliste übersehen!
Hier noch eine Auffälligkeit in den Fenstern “Suchanfrage” und “Erweiterte Suche”:
Außerdem lässt sich das Fenster “Suchanfrage” nicht vergrößern. Beim Fenster “Erweiterte Suche” funktioniert das.
