Hallo zusammen!

Ich erweitere gerade ein SQL-Modul, welches neu auch eine Umsetzung
von Suchstrings in SQL erlauben sollte...

Wenn man etwas rumschaut, sieht man sehr viele unterschiedliche
Implementationen bsp. der Wildcards!
Was meint ihr, wie sollte man ein Textfeld umsetzen - sprich
welche Zeichen sind am besten geeignet für Endbenutzer für
Suchbefehle?
In diesem Moment spreche ich noch nicht von "Codezeilen" die ich
hier zur Diskussion stellen möchte!

Aktuelle Implementation: Immer "%eingabe%" Sprich keine Wildcards
und die Eingabe wird als gesamter Teil im Inhalt gesucht..
Ziel: Ohne Wildcards sinnvolles tun, Mit wildcards sinnvolles tun,
und mit UND oder OR Verknüpfungen arbeiten können!

Eine reine Anlehnung an Google ist hier nicht sinnvoll, da das
Ziel nicht dasselbe ist und Google auch mehr bietet als ich will
(Ähnliche Wörter finden lassen wir mal weg!)

Mögliche Lösung:
Legende:
& AND -> und Verknüpfung
| OR -> oder Verknüpfung
"text" -> wird als EIN Element gematcht, egal ob Abstände drin sind
! NOT -> Invertierung der Suchlogik (Ausschluss der zutreffenden)
* -> Mehrbuchstaben Wildcard
? -> Einzelbuchstaben Wildcard

Problem mit Endbenutzer ist immer noch das Escaping. Da die meisten
dies so oder so nicht verstehen, würde ich hier von Vornherein
diese Zeichen als Suchtext-Zeichen verbieten und das Problem mal
eliminieren :-)

Wir nehmen also ein Suchbegriff auf erster Stufe auseinander:

EINGABE wird eingegeben und hier mit 'EINGABE' aufgeschrieben und
vorwärts untersucht..
Wir zerhacken auf erster Stufe in Einzelwörter oder Suchelemente.
Eine EINGABE='wort1 wort2' wird also aufgeteilt in zwei Begriffe:
'wort1' und 'wort2'. Da vor Wort2 keine Verknüpfung steht,
heisst dies automatisch AND. Da beide Wörter keine Wildcards
verwenden heisst dies automatisch '*wort1*' und '*wort2*'.

Fall TEILWORT hat kein " im Ausdruck:
Hier gilt automatisches Anfügen von * (vorne und hinten)
Hat der Suchbegriff jedoch schon ein * oder ? drin wird darauf
verzichtet!
Es erfolgt ein einfaches Umsetzen in SQL-Wildcards.

Fall TEILWORT von Doublequotes umschlossen:
Kein automatisches Anfügen von *
Wildcards innerhalb der Quotes werden jedoch berücksichtigt.

Beispiel 2:
EINGABE='Hund* OR Katze AND *Vogel | "Ente"'
Reduzierung:
WORT1='Hund*' -> Suche nach 'Hund*'
WORT2='OR Katze' -> Suche nach '*Katze*' mit OR-Verknüpfung
WORT3='AND Katze' -> Suche nach '*Vogel' mit AND-Verknüpfung
WORT4='OR Ente' -> Suche nach 'Ente' (exakt) mit OR-Verknüpfung

Verbesserungsvorschläge?

GrEeZ: Miro Dietiker

Ich würde lediglich folgendes nehmen:

Input Field: (Suchausdruck)
daneben/darunter Radio-Buttons: "match exact string" und "match any string"

sowie unerwünschte Begriffe rausfiltern:

Statt Invertierung mit !NOT würde ich aber das Minuszeichen wählen. z.B. ein separates Formularfeld
"OHNE diesen Suchausdruck": ______

Was Du auch machen solltest (je nach Aufbau der Seite natürlich) ist eine Eingrenzung nach Sachgebieten oder Site-Kategorien.
z.B. "Suche in: a) News b) Produktbeschreibungen c) Supportforum d) gesamter Seite"
um die Suche schlicht einzugrenzen und zu beschleunigen.


Ich nehme an Du bist mit Boolean Fulltext-Suche in mySQL vertraut. Falls nicht, schau mal hier rein:
http://dev.mysql.com/...ulltext_Boolean.html
http://www.onlamp.com/.../06/26/fulltext.html
http://www.devarticles.com/...page=0&hide_js=1

SELECT * FROM articles WHERE MATCH (title,body) AGAINST ('+MySQL -YourSQL' IN BOOLEAN MODE);

d.h. wenn der User das genau so eingibt:
+MySQL -YourSQL
ergibt das automatisch die "richtige" Suche nachher in der DB, und ist glaubs auch für Computer-Analphabeten verständlich.

Folgendes Detail ...

Diese Eingabemethode soll in allen Eingabefeldern neu supportet
sein. In der gesamten Administration gild damit in allen
spezifischen Suchfeldern diese Regeln. Wir sprechen üblicherweise
hier NICHT von einer Volltextsuche in einem "Content-haufen" wie
das google macht, sondern von klassifizierten Feldern...

Nicht erwünscht ist jedoch der Effekt, dass ich pro solches
Eingabefeld dann noch ein zusätzliches (Checkbox) oder sonst
was am Frontend darstellen muss ...

Wegen dem BOOLEAN MODE folgendes:
"As of Version 4.0.1, MySQL can also perform boolean full-text searches using the IN BOOLEAN MODE modifier."

Und das ist schon der Grund, weshalb ich's nicht nehmen kann...
Grundlegend jedoch möchte ich auch keine FULLTEXT-Indizes dafür
verwenden, da es sich wirklich um "Ein Feld pro Spalte" für die
Durchsuchung der DB handelt ...

Das Fulltext-Problem klassifiziere ich aus meiner Sicht an einem
anderen Ort...

Das mit dem - finde ich heikel... ist doch das "-" ein Zeichen
welches man häufig verwendet und auch in der Suche als Content
supportet sein soll! Man könnte hier in der Implementation ja
eine Ausnahme machen, aber ich muss mir das mal überlegen wie
das genau wirkt in der Nutzung usw...

GrEeZ: Miro Dietiker

Heisst das, Du gedenkst überall LIKE '%blah%' usw. zu verwenden?

"Das mit dem - finde ich heikel... ist doch das "-" ein Zeichen
welches man häufig verwendet"

Ja, aber nur als Verbindungs-Strich. Nicht am Anfang eines Begriffs.
Niemand such nach "-Zürich" (aber vielleicht nach "Zürich-Rom").

Es hat sich auf den meisten Suchseiten nun mal so eingebürgert, und man sollte bekanntlich nicht gegen alte Gewohnheiten kämpfen...

d.h. Du wirst nicht um ein paar Regex-Uebungen herumkommen :)


OR = würde ich schlicht vergessen, und das schlicht als die Standardmethode nehmen (d.h. falls AND Abfragen nichts ergeben)

& AND -> und Verknüpfung
AND durch + ersetzen. Nur EIN Symbol oder Wort anbieten, nicht mehrere.

! NOT -> Invertierung
Ausschluss wie gesagt durch -
Enduser sind ja vermutlich keine Programmierer...

Schau .. Bsp. Usermanagement:
Die Suchmaske hat folgende Kriterien
- Benutzername -> $username
- Email -> $email
- ...

Man kann sich das so vorstellen:

Anstelle der früheren Implementation
$sql = "SELECT ...";
$sql .= " WHERE 1=1";
if(strlen($username))
{ $sql .= " AND username LIKE %".escape($username)."%"; }

Kommt neu
$sql = "SELECT ...";
$sql .= " WHERE 1=1";
if(strlen($username))
{ $sql .= sql_expand_search('username', $username); }

Für JEDE Feldsuche (ca 50 Suchmasken oder so).
Alle Masken bleiben Gleich, Keine Popups, keine neuen Felder.
Werden keine Sonderzeichen verwendet, resultiert dieselbe
String-Konstellation. Sprich: Bsp. 2 wird zu 1 nach expansion

Dass du mir jetzt nicht sagst "so geht das nicht mit dem String
und dem Anfügen des" muss ich noch sagen:
Bei mir ist $sql ein Objekt und ein "Abstraktes query" sprich:
es heisst vom Verständnis her:
$sql->Where(sql_expand_search('username', $username);

Schliesslich wird aber das voll eingebettet in das abstrakte Query:
$sql->WhereExpand('username', $username);

Fertig!

GrEeZ: Miro Dietiker