MYSQL Regexp

[Andi]

Hi,

ich versuche eine Query zu erstellen, die überprüft, ob Suchwörter vorkommen. Beide Suchwörter müssen vorkommen und die Reihenfolge ist egal.

Also:

SELECT *
FROM test
WHERE title REGEXP a.*b.*|b.*a.*

Auch wenn Zeilenumbrüche vorkommen sollen sie gemacht werden. Aber es funktioniert nicht.

Was ist denn an dieser Query falsch?

Gruß
Andi

[Cheatah]

Hi,

Beide Suchwörter müssen vorkommen und die Reihenfolge ist egal.

das macht man mit AND, nicht mit Regular Expressions.

Auch wenn Zeilenumbrüche vorkommen sollen sie gemacht werden. Aber es funktioniert nicht.

Der Punkt matcht alles bis auf Umbrüche.

Cheatah

[Andi]

Hi,

das macht man mit AND, nicht mit Regular Expressions.

Ja leider sollen auch Wörter wie "Abfrage" oder "Colin Mc Rae boom" gefunden werden.

Wie soll ich das dann mit AND lösen?

Was kann man angeben beim Regex das er auch den Zeilenumbruch matcht? (So wie s-modifier in PHP)

Gruß
Andi

[Cheatah]

Hi,

Ja leider sollen auch Wörter wie "Abfrage" oder "Colin Mc Rae boom" gefunden werden.

wo ist das Problem?

Wie soll ich das dann mit AND lösen?

"Suchbegriff 1 vorhanden AND Suchbegriff 2 vorhanden"

Was kann man angeben beim Regex das er auch den Zeilenumbruch matcht? (So wie s-modifier in PHP)

Was sagt die Dokumentation Deines DBMS hierzu?

Cheatah

[Andi]

Hi,

"Suchbegriff 1 vorhanden AND Suchbegriff 2 vorhanden"

wird es dann nicht langsamer, weil ich ja mit like arbeiten muss. (Wenn mehrere Suchwörter vorkommen können < 15)
Das wird so eine Art Sitemap und Sitesearch.

Mit regexp bleibt es aber dennoch akzeptabel

Gruß
Andi

[Sven Rautenberg]

Moin!

"Suchbegriff 1 vorhanden AND Suchbegriff 2 vorhanden"

wird es dann nicht langsamer, weil ich ja mit like arbeiten muss. (Wenn mehrere Suchwörter vorkommen können < 15)

LIKE wird dann langsam, wenn du eine Wildcard voranstellst, weil du "...irgendwasSUCHWORTirgendwas..." suchst. Dann muß die gesamte DB durchgegangen werden, und Indizes bleiben komplett ungenutzt.

Genau dasselbe muß aber auch passieren, wenn du deinen regulären Ausdruck verwendest, der am Anfang beliebige Zeichen erlaubt.

Mit regexp bleibt es aber dennoch akzeptabel

Reguläre Ausdrücke sind im Gegensatz zu LIKE noch performanceaufwendiger, wenn man nur rein den Vergleichsvorgang "Gesuchtes Muster" mit "gefundener DB-Eintrag" betrachtet.

Deshalb: Wenn du auf reguläre Ausdrücke verzichten kannst (und das kannst du hier), dann verzichte drauf.

- Sven Rautenberg

[Andi]

Hi,

ich werde es so lösen, wie kann man es aber trotzdem mit einer REGEX lösen?

Gruß
Andi

[Sven Rautenberg]

Moin!

ich werde es so lösen, wie kann man es aber trotzdem mit einer REGEX lösen?

Die Aufgabenstellung "mehr als zwei Suchbegriffe können in beliebiger Reihenfolge in einem String vorkommen, müssen aber alle vorkommen" sollte man nicht per RegEx lösen. Denn du mußt für jede Anzahl an Suchbegriffen einen eigenen Regex bereithalten, in dem alle Permutationen (d.h. Reihenfolgemöglichkeiten) aller Begriffe aufgeführt sind:

Für zwei Begriffe ist das noch leicht, denn es gibt als Reihenfolge nur:
AB oder BA

Bei drei Begriffen ist das schon schwieriger:
ABC oder ACB oder CAB oder BAC oder BCA oder CBA

Bei vier Begriffen gibt es schon 12 verschiedene Anordnungsmöglichkeiten.

Bei den von dir in Aussicht gestellten zehn Begriffen gibt es 10! (zehn Fakultät) verschiedene Anordnungsmöglichkeiten. Das sind 3628800 Stück.

Da ist es doch sehr viel einfacher, einfach eine AND-Verknüpfung mit jedem der zu findenden Begriffe zu machen. Da hat man maximal soviele AND-Komponenten, wie Begriffe.

Ein Regex würde dir tatsächlich nur helfen, wenn es wirklich um Mustererkennung ginge, du also "hier zehn Buchstaben, dann drei Ziffern, dann beliebige Zeichen, dann 'true' oder 'false'..." suchst. Wann immer du feststehende (auch dynamisch vom Benutzer eingebbare) Strings suchst, sind reguläre Ausdrücke unbedingt zu vermeiden.

- Sven Rautenberg

[Andi]

Hi,

da hast du vollkommen recht. Da ist eine AND-Verknüpfung durchaus vernünftiger.
Könnte man das auch beim Gewichten der Suchergebnisse einsetzte?
D.h., wo alle vorkommen kommt als erste sonst als zweites usw.

Aber das würde dann kompliziert, oder?

Gruß
Andi

[wahsaga]

hi,

Da ist eine AND-Verknüpfung durchaus vernünftiger.

wenn du keine wildcard-suche brauchst, wäre eine volltextsuche vielleicht auch eine alternative.

Könnte man das auch beim Gewichten der Suchergebnisse einsetzte?
D.h., wo alle vorkommen kommt als erste sonst als zweites usw.

Aber das würde dann kompliziert, oder?

nein, mit FULLTEXT nicht, das ordnet nämlich automatisch nach relevanz.

informiere dich mal im mysql-manual darüber.

gruß,
wahsaga

[Sven Rautenberg]

Moin!

Hi,

da hast du vollkommen recht. Da ist eine AND-Verknüpfung durchaus vernünftiger.
Könnte man das auch beim Gewichten der Suchergebnisse einsetzte?
D.h., wo alle vorkommen kommt als erste sonst als zweites usw.

Aber das würde dann kompliziert, oder?

Richtig, das ließe sich mit einer einzigen SQL-Abfrage wahrscheinlich nicht so einfach realisieren. Wenn dein Abfrageergebnis nach Relevanz sortiert werden soll, wäre dazu ja eine Spalte "relevanz" notwendig, auf die du ORDER BY relevanz anwenden kannst. Damit die Relevanz aber irgendwie notiert wird, müßtest du im einzelnen feststellen, wieviele der Suchwörter tatsächlich gefunden wurden. Das zu formulieren wird vermutlich sehr aufwendig.

Es dürfte wahrscheinlich einfacher sein, diese Feststellung hinterher in der Programmiersprache zu treffen. D.H. wenn du alle Einträge haben willst, in denen auch nur ein einziger der Suchbegriffe vorkommt, mußt du statt "AND" natürlich mit "OR" verknüpfen, das Ergebnis dann in ein Array einlesen und nochmal nachsortieren.

Alternativ könntest du deine Datenbank natürlich auch um einen vernünftigen Suchindex erweitern. Die "neue" SELFHTML-Suche beispielsweise gibt die Suchergebnisse nach Relevanz sortiert aus, wobei hier ein Wertungsschema zum Einsatz kommt: Suchworte in der Postingüberschrift sind beispielsweise wichtiger, als wenn sie nur im normalen Text vorkommen. Aber so ein System aufzuziehen ist nicht sehr einfach - und außerdem sorgt es für eine fette Menge an zusätzlichen Daten für diesen Index, die zudem noch relativ aufwendig generiert werden müssen. Das Indizieren des gesamten Forumsarchivs seit 1998 hat jedenfalls (wenn ich es richtig erinnere) eine Woche gebraucht.

Ich würde deshalb von solchen Operationen lieber absehen. Solange man irgendwas findet, sollte das erstmal ausreichen. :)

- Sven Rautenberg