Erweiterte Suche

StefanE · August 21, 2011, 10:38pm

Hi,

eine erweiterte Suche wäre schön. Wir könnten hier gerade folgendes gebrauchen:

[ol][li]In der Bibliothek suchen nur innerhalb eines oder mehrerer Ordner.[/li]
[li]Ein Flag für die Elemente in der DB, die bei der Suche ausgenommen werden, also nicht in den Suchergebnissen erscheinen.[/li]
[li]Suchen nach z.B. Album, Komponist, etc. [/li]
[li]Verhalten der Suche bei Eingabe von Leerzeichen und z.B. Bindestriche, Semikola usw.: Diese Zeichen sollten ignoriert werden, sodass die Suche die Titel auch findet, wenn ich nicht weiß, ob der Titel “its so” oder “it’s so” heißt. Noch praktischer wäre es, wenn Umlaute auch egal wäre, sodass ich “chanté” auch dann finde, wenn ich “chante” eingebe, oder auch Floß/Floss usw.[/li][/ol]

Soweit erstmal. Vielleicht fällt uns noch mehr ein.

Radio4Players · June 16, 2012, 9:41am

Eine erweiterte such ewürde ich auch begrüßen, z.b. nach Album

Die Option in der DB unter Attribute finde ich persönlich zu umständlich während der Sendung.

StefanE · May 1, 2015, 4:58pm

Gerade wollte ich danach fragen und merke: Ich habe das ja schon mal gefragt.
Gibt’s in der Richtung was neues?

Wir haben als Veranstaltungsradio den Fall, dass wir einige Jingles jedes Jahr neu produzieren (müssen). Die alten (z.B. mit veralteten Sponsoren/Frequenzen/…) bleiben in der Datenbank. In der Suche tauchen sie aber alle mit auf.
Deshalb wäre es besonders wünschenswert, dass man

für die Standardsuche festlegen könnte, welche Ordner ausgenommen bzw. inbegriffen sein sollen (inkl. Unterordner ja/nein)
ein erweiterter Such-Dialog, bei dem man die Suche weiter einschränken könnte.

Weiterhin wäre es schön, wenn im Suchergebnis weitere Spalten einblendbar wären (z.B. Album etc.).

Grüße!

Radio4Players · May 1, 2015, 5:49pm

probier mal rechte maustaste, da hast dann auswahl ?

z.b. interpret, title etc.

StefanE · May 2, 2015, 12:50am

Danke, Radio4Players. Aber die Funktion kenne ich schon.
Dennoch werden dabei immer alle Ordner durchsucht.

Unter einem erweiterten Suchdialog stelle ich mir auch sowas vor wie:
Suche nach “love” im Titel und in Jahr zwischen 1980 und 2010 - oder sowas in der Art.

Radio4Players · May 2, 2015, 3:34pm

ich habs geahnt , stefan, aber ich hol den hier noch mal raus:

[quote=“Radio4Players, post:2, topic:7523”]Eine erweiterte such ewürde ich auch begrüßen, z.b. nach Album

Die Option in der DB unter Attribute finde ich persönlich zu umständlich während der Sendung.[/quote]

StefanE · September 2, 2015, 10:54am

Ich krame das Thema mal wieder hoch, weil ich immer wieder darauf stoße.

Bevor wir weiter über eine große Lösung sprechen, wäre es doch eine recht einfache Möglichkeit, ein “Archiv” einrichten zu können.
Anders ausgedrückt: Man bräuchte “nur” ein Archiv-Flag zum Beispiel für Ordner (inkl. Unterordner).
Faktisch haben wir bei uns bereits einen Ordner, der “Archiv” heißt, man müsste mAirList jetzt nur noch beibringen, diesen Ordner auch als Archiv zu erkennen und nicht in der Suche zu berücksichtigen.

Nächste Stufe: Bei den Suchfeldern eine Option “Archiv-Ordner durchsuchen ja/nein”.

Wenn das einfach umzusetzen wäre, würde ich mich extrem freuen, wenn Du sowas in der Art mal einbauen könntest, Torben. Am liebsten ganz bald, aber ich weiß, dass Du viel zu tun hast und die ToDo-Liste lang ist.

Viele Grüße aus Butzbach
Stefan

StefanE · July 7, 2016, 10:29pm

Heute haben wir neuen Mitarbeitern die Suchfunktion gezeigt und wieder darauf hinweisen müssen, dass die Suche nicht so funktioniert, wie sie es heute in Zeiten von Google gewohnt sind:

Eine Suche nach “its been” findet nix, wenn es nur Titel mit “it’s been” gibt.
Eine Suche nach “Love of live” findet “The Love of my life” nicht.
Eine Suche nach “Andre” findet “André” nicht.
Usw.

Ist denn keine Lösung in Sicht? Nervt das sonst niemanden?
Ich werde regelmäßig gefragt, warum das so ist.

Auch für das andere von mir angesprochene Problem haben wir weiterhin keine Lösung: Veraltete, “verbotene” oder noch nicht freigegebene Elemente können nicht aus der Suche ausgenommen werden. Das ist wirklich immer wieder sehr störend.

Darum erneuere ich mal wieder unseren Wunsch.

Was meint der Doktor dazu?

Torben · July 8, 2016, 7:32am

Bei Google stehen Tausende Server mit terabyteweise Speicher im Hintergrund, die eine fortlaufende Volltext-Indizierung durchführen. Das kann deine kleine SQL-Datenbank nicht.

StefanE · July 8, 2016, 8:09am

Naja, es geht ja nicht darum, dass ich eingebe “lobe” und mAirList fragt: “Meintest Du ‘love’”.

Sehr hilfreich wäre schon, wenn ich nach “love of life” suche und er “The Love of my life” auch ausspuckt. Dazu müsste mAirList die Wörter einzeln betrachten und nicht den gesamten String. Wenn man wirklich den gesamten String suchen möchte, würde man dann die Suche in Anführungszeichen einschließen. Das ist ja eigentlich ein sehr altes Konzept, das Nutzer von vielen anderen Programmen kennen.

Auch Satzzeichen müsste man doch eigentlich gut rausfiltern können.

Bei den Accents wird es natürlich etwas aufwändiger, da man dazu ja eine komplette Ersetzungsliste haben müsste (e=é=è=ê=ë usw.). Meine Hoffnung ist ja, dass es sowas irgendwo schon als Funktion oder Bibliothek gibt, und man es nicht selbst programmieren muss.

Torben · July 8, 2016, 7:06pm

Suchvorschläge meinte ich gar nicht.

Ich meinte, dass Google einen Suchindex besitzt. Wenn du einen Suchbegriff eingibst, durchsucht Google ja nicht jede Website einzeln, sondern es hat irgendwo eine List angelegt, welche Begriffe auf welchen Seiten vorkommen. Einen Suchindex eben.

Weiterhin musst du dir vor Augen halten, dass mAirList nicht “selbst” sucht, sondern es deligiert die Suchanfrage an die SQL-Datenbank:

SELECT idx FROM items WHERE title LIKE '%suchbegriff%' OR artist LIKE '%suchbegriff%';

("Gib mir die IDs aller Elemente, deren Interpret oder Titel den “suchbegriff” als Substring enthält.)

Andernfalls müsste nämlich mAirList bei jede Suche alle Datensätze erstmal aus der Datenbank über das Netzwerk ins RAM transferieren, und dort dann seinen eigenen Suchalgorithmus drüber laufen lassen. Das wäre sehr viel langsamer, als wenn die Datenbank gleich die passenden Datensätze zurückliefert.

Nun sind aber die Suchmöglichkeiten innerhalb der SQL-Sprache nicht besonders umfangreich. Das Beispiel von oben mit dem Substring ist schon das höchste der Gefühle - und hat zudem noch den Nachteil, dass die Datenbank alle Datensätze angucken muss. Besser wäre, man würde nur nach “fängt an mit” oder “entspricht genau” suchen, dann könnte man einen klassischen Index verwenden.

PostgreSQL hat wohl eine proprietäre Erweiterung, mit Hilfe derer man sich echt Suchindexe aufbauen kann:

https://www.postgresql.org/docs/9.5/static/textsearch.html

Sowas würde dann wohl in die Richtung gehen, die du dir vorstellst. Aber damit habe ich mich noch nicht beschäftigt.

StefanE · July 10, 2016, 10:49pm

Danke für die ausführliche Erläuterung.

[quote=“Torben, post:11, topic:7523”]SELECT idx FROM items WHERE title LIKE '%suchbegriff%' OR artist LIKE '%suchbegriff%';

("Gib mir die IDs aller Elemente, deren Interpret oder Titel den “suchbegriff” als Substring enthält.)

Andernfalls müsste nämlich mAirList bei jede Suche alle Datensätze erstmal aus der Datenbank über das Netzwerk ins RAM transferieren, und dort dann seinen eigenen Suchalgorithmus drüber laufen lassen. Das wäre sehr viel langsamer, als wenn die Datenbank gleich die passenden Datensätze zurückliefert.[/quote]

Aber gibt es nicht noch eine einfachere Möglichkeit?: mAirList müsste zunächst den Such-String in Teilstrings zerlegen. Aus “where is love” wird dann “where”, “is” und “love”.
Dann würde man für jeden dieser Teilstrings die von Dir beschriebene Suchanfrage stellen.
Da die Suchanfrage nach meinem Verständnis ja eine UND-Suche wäre, müsste dann in den Suchergebnissen geschaut werden, welche Einträge in allen drei Suchergebnislisten vorkommen. Und diese würden dann ausgegeben.

Nach meiner Vorstellung würde genau so gesucht werden, wenn der Benutzer mehrere Wörter (durch Leerzeichen getrennt) in das Suchfeld eingibt. Wenn er so suchen möchte wie bisher (gesamte Eingabe ins Suchfeld so genau so vorkommen), dann muss der Benutzer das ganze in Anführungszeichen eingeben.

Würde auch dieses Verfahren zu lange Abfragezeiten verursachen?

Nicht gelöst würde dadurch die Sache mit Satzzeichen und Accents.

Was meinst Du zu meinem zweiten hier im Thread angesprochenen Thema bzgl. der Ausnahme von Elementen aus den Suchergebnissen. Ich hatte ja schon vor längerem vorgeschlagen, ein entsprechendes Flag dafür zu schaffen, das z.B. “Archiv” oder eben einfach “nicht in Suchergebnissen anzeigen” heißen könnte.

StefanE · July 10, 2016, 10:51pm

Okay, ich habe gerade weiterüberlegt. Allein die Suche nur nach “is” würde natürlich sehr viele Ergebnisse liefern. Dann dauert das wohl doch zu lang?

StefanE · July 10, 2016, 11:52pm

oder gleich entsprechend viele ANDs in die Abfrage bauen, also so in der Art:

SELECT * FROM items WHERE (title ILIKE '%Jackson%' OR artist ILIKE '%Jackson%') AND ( title ILIKE '%World%' OR artist ILIKE '%World%');

… liefert genau das, was wir uns wünschen.

Das zeigt auch das, was wir uns besonders wünschen: Als Stichwörter den Interpret (oder einen Teil des Interpretennamens) eingeben und ein, zwei Wörter aus dem Titel.

Viele Grüße aus Butzbach!

PS: Lob übrigens für die neue SQL-Konsole in der mAirListDB! Sehr praktisch.

ssnoopy · July 11, 2016, 7:22am

Das funktioniert aber nur, wenn du einen Suchstring hast.
Bei einer suche von “Atemlos die Nacht”
Wird jedoch nicht der Titel “Atemlos durch die Nacht” gefunden.
Und, genau darum ging es ja

StefanE · July 11, 2016, 10:39am

Hi ssnoopy,

doch klar:

Der gesamte Suchstring “Atemlos die Nacht” würde zunächst in n Teilstrings zerlegt, wobei n die Anzahl der Wörter ist, die durch Leerzeichen getrennt sind. In Deinem Beispiel sind es drei.

Es würde also nach “Atemlos” und “die” und “Nacht” gesucht, und zwar in den Feldern titel, artist usw.
Bedingung ist, dass alle n Teilstrings vorkommen (AND), dabei ist es egal, in welchem Feld der Teilstring vorkommt (OR innerhalb der Klammern).

Dementsprechend würde gefunden:
“Atemlos durch die Nacht”
“Atemlos ist die Nacht”
“Die Nacht macht mich atemloser als der Tag”
“Nachtigallenlied” von “Die Atemlosen”
“ATMO Mann joggt atemlos, im Hintergrund die Nachtigall”
“TRAILER Aktion Die Atemlose Nacht am 11.07.2016 - präsentiert von Radio XYZ”.

StefanE · July 16, 2016, 1:16pm

Heute habe ich noch mal Zeit, hierzu etwas zu schreiben. Wir möchten gerne eine Lanze für die Suche in der von uns vorgeschlagenen Form brechen.

Das Entscheidene ist eigentlich, dass wir bei unseren Versuchen mit der SQL-Konsole festgestellt haben, dass die Suche nach mehren Strings sehr gut und schnell funktioniert, nämlich mit dem genannten Beispiel:

[quote=“StefanE, post:14, topic:7523”]SELECT * FROM items WHERE (title ILIKE '%Jackson%' OR artist ILIKE '%Jackson%') AND ( title ILIKE '%World%' OR artist ILIKE '%World%');[/quote]

In diesem Beispiel wird nach “Jackson” und “World” gesucht, und zwar in artist und title. Dabei wird geschaut, ob beide Wörter (AND) irgendwo in artist ODER title vorkommen.

Ins Suchfeld würde der Nutzer dazu eingeben: [tt]Jackson World[/tt] oder [tt]World Jackson[/tt].
mAirList müsste zunächst diesen Suchstring in einzelne Wörter zerteilen ([tt]Jackson[/tt] und [tt]World[/tt]).

(Außerdem müssten nicht nur artist und title, sondern auch z.B. album, ID durchsucht werden, jenachdem, was der Benutzer mit Rechtsklick auf das Suchfeld angehakt hat.)

Je nach Anzahl der Wörter würde mAirList dann die Datenbankabfrage zusammenstellen:

SELECT * FROM items WHERE (title ILIKE '%Suchwort1%' OR artist ILIKE '%Suchwort1%' OR album ILIKE '$Suchwort1' …) AND (title ILIKE '%Suchwort2%' OR artist ILIKE '%Suchwort2%' OR album ILIKE '$Suchwort2' …); AND (… Suchwort3 …) AND (… Suchwort4 …) … ORDER BY title

Die Datenbank würde nach dieser Abfrage genau das gewünschte Suchergebnis liefern.

Vorteile:
Der Nutzer könnte dann eine beliebige Zahl an Wörtern eingeben, die ihm aus dem Titel, Interpreten, Album etc. einfallen, um die Suche einzugrenzen.
Wenn er den genauen Titel nicht mehr weiß: kein Problem! Die Suche findet es.
Er weiß die Reihenfolge der Wörter z.B. im Titel nicht mehr (Irgendwas mit “Heal World”)? Kein Problem! Die Suche findet es.

Nachteile:
Mir fallen keine ein.
Um die string-genaue Suche weiterhin zu ermöglichen, sollte der Nutzer seine Suche (oder Teile davon) in Anführungszeichen setzen können. (Ich glaube, das ist sogar standardmäßig so bei irgendeiner Delphi-Methode zum Splitten eines Strings in meherere Wörter.)

Nachteile der bisherigen Suchfunktion:
Bei der derzeitigen Suche von mAirList habe ich keine Chance, etwas zu finden, wenn ich [tt]Jackson Heal the World[/tt] eingebe, denn der genaue String kommt so nirgends vor. D.h. ich muss mir derzeit damit behelfen, lieber nur nach [tt]World[/tt] zu suchen, wenn ich die genaue Reihenfolge der Wörter nicht mehr weiß.

Wie bewältigt Ihr das, wenn Ihr nach einem Song sucht, dessen Titel Euch gerade nicht einfällt? Google bemühen und dann in mAirList suchen? Gibt es diesen Fall bei Euch nicht?
Unsere Redakteure und Moderatoren fragen mich regelmäßig, warum mAirList nichts findet, wenn sie nach [tt]Jackson World[/tt] u.ä. suchen, der Titel sei doch im Archiv. Dann erkläre ich das.

Daher fände ich es wirklich super, wenn die Suche auf diese Weise einfach mehr den Gewohnheiten der Nutzer entsprechen würde.
Nach unserem Rumprobieren mit der SQL-Konsole bin ich recht überzeugt, dass es doch recht einfach gehen müsste. Wir haben auch keine Verlangsamung der Suche bemerkt.

Oder haben wir irgendwas übersehen?

Viele Grüße aus Butzbach!

Torben · July 16, 2016, 8:02pm

Solange du nur in Interpret, Titel und Kommentar suchst - allesamt Spalten der Tabelle “items” - funktioniert das.

In dem Moment, wo du auch in Attributen suchen willst (z.B. Album), klappt das o.g. nicht mehr. Denn diese Attribute sind nicht Spalten von “items”, sondern sie stehen als key/value-Paare in der Tabelle “item_attributes”.

Anders gesagt: Die Tabelle “items” hat gar keine Spalte “album”. Das wäre euch aufgefallen, wenn ihr dein zweites SQL-Beispiel auch tatsächlich in der SQL-Konsole ausprobiert hättet. Punkt für mich

Theoretisch könnte man jetzt natürlich einen riesigen JOIN über items und (mehrfach) items_attributes machen; dazu müssten allerdings die Namen aller Attribute zur Übersetzungszeit bekannt sein. Und das widerspricht ja gerade dem “offenen” key/value-Konzept der Attribute in mAirList.

Aktuell funktioniert der Suchalgorithmus in etwa so:

Erzeuge eine temporäre Tabelle
Trage die IDs aller Elemente aus “items” ein, die zu den Suchbegriffen passen (1-2 SQL-Anfragen, je nachdem ob man nach Lauflänge sucht oder nicht).
Trage die IDs aller Elemente aus “item_attributes” ein, die zu dem Suchbegriff passen (1 SQL-Anfrage).
Ermittle die Daten zu den Elementen, deren IDs in der temporären Tabelle stehen, und schreibe sie in die Ausgabe (mehrere SQL-Anfragen auf verschiedenen Tabellen).
Lösche die temporäre Tabelle

Die eigentliche Suche nach den passende IDs benötigt also 2-3 SQL-Anfragen (Schritt 2 und 3), hinzu kommen am Ende die Anfragen, die die Playlist-Elemente tatsächlich laden (Schritt 4).

Die von dir gewünschte Semantik ist ja im Grunde, dass die einzelnen Wörter im Suchstring UND-Verküpft sein sollen. Die einzige Möglichkeit, die ich dazu sehe, ist dass die Schritte 2 und 3 je Suchbegriff in einer Schleife wiederholt und dann die Listen entsprechend gefiltert werden:

Erzeuge zwei temporäre Tabellen temp1 und temp2
Trage in temp1 die IDs aller Elemente aus “items” ein, die zu dem i-ten Suchbegriff passen (1-2 SQL-Anfragen, je nachdem ob man nach Lauflänge sucht oder nicht).
Trage in temp1 die IDs aller Elemente aus “item_attributes” ein, die zu dem i-ten Suchbegriff passen (1 SQL-Anfrage).
Falls i=1 (erster Suchbegriff): Kopiere temp1 nach temp2; bei i > 1 (zweiter und weiterer Suchbegriff): Lösche alle IDs aus temp2 die nicht in temp1 stehen. (jeweils 1 SQL-Anfrage)
Falls weitere Suchbegriffe vorhanden: Springe zu 2.
Ermittle die Daten zu den Elementen, deren IDs in temp2 in der temporären Tabelle stehen, und schreibe sie in die Ausgabe (mehrere SQL-Anfragen auf verschiedenen Tabellen).
Lösche temp1 und temp2.

Die Anzahl der SQL-Anfragen steigt also linear mit der Anzahl der Suchbegriffe. Wenn ihr damit leben könnt…

Torben · August 18, 2016, 12:39pm

Wird im kommenden Snapshot 3161 drin sein. Als Häkchen “Erweiterte Suche” im Kontextmenü des Suchfeldes, dort wo man auch die zu durchsuchenden Felder auswählt.

StefanE · September 7, 2016, 9:27pm

Hey Torben, supercool!

Ich habe leider in den vergangenen Wochen keine Zeit gefunden, über die Sache noch mal nachzudenken und dazu was zu schreiben. Aber Du offenbar. Sehr schön!

Gestern habe ich das aktuelle Snapshot installiert. Der Jubel war groß. Wir freuen uns sehr über die Funktion! Vielen Dank!

By the way: Für unser Problem, dass die inaktiven Elemente (z.B. derzeit nicht zu verwendende Jingles/Sponsoren-Trailer etc.) nicht ausgeblendet werden können, haben wir einen Workaround gebaut: Betreffenden Elementen wir in Interpret und Titel ein “ZZZ |” vorangestellt. So erscheinen diese Elemente bei Suchergebnissen i.d.R. ganz unten.
Natürlich hat André, der das bei uns macht, dazu eine Massenbearbeitung entsprechend gekennzeichneter Elemente über Access implementiert

Viele Grüße aus Butzbach

Stefan
und die WeWeWe-Crew