nicht angemeldet
Hi Andreas,
- Wirklich gut wird die Suche aber nur, wenn Du mehr
als einen Suchbegriff erlaubst.
mache ich doch !? Du kannst eingeben was Du willst,
MySQL zerteilt des String selbst udn sucht nach dn
einzeknen Wörtern. Das dumme ist nur, es müssen
nicht alle Wärter gefunden werden, du das macht das
ganez natürlich abhängig von der Qualität des
Rankings, und das ist das Problem!
Eben. Deshalb ist diese Methode nicht so arg toll.
Ich parse die Eingabestrings selbst und generiere mir
daraus eine WHERE-Klausel, die pro Term ein AND mit
einem separaten FULLTEXT-MATCH enthält. Ich erzwinge,
daß alle Terme drin sein müssen. Und das ist selbst
mit mySQL 3.23 ziemlich schnell - und ich kriege sehr
kleine Treffermengen, wenn ich genügend Terme angebe.
Naja, jetzt habe ich das komplette Archiv 2002,
das reicht zum probieren aus, denke ich!
Ack.
Warum ich unbedingt 4 haben möchte hat folgende
Gründe(Zitat):
REPAIR TABLE mit FULLTEXT-Indexen, ALTER TABLE
mit FULLTEXT-Indexen und OPTIMIZE TABLE mit
FULLTEXT-Indexen läuft jetzt bis zu 100 mal
schneller.
Nichts davon brauchst Du im Normalbetrieb. REPAIR
brauchst Du hoffentlich nie, ALTER TABLE auch nicht,
sobald Deine Tabelle Suche fertig ist; OPTIMIZE auch
nur ein einziges Mal, wenn überhaupt (ich benutze das
gar nicht).
MATCH ... AGAINST wird folgende Boolesch
Operatoren unterstützen:
Ja, es wird besser. Aber das sind "nice to have"-
Funktionen, finde ich.
* +wort bedeutet, dass das Wort in jeder
zurückgegebenen Zeile enthalten sein muss.
* -wort bedeutet, dass das Wort in jeder
zurückgegebenen Zeile nicht enthalten sein darf.
Beides ist durch entsprechend generierte WHERE-
Klauseln schon jetzt möglich.
* < und > können benutzt werden, um die
Wortgewichtung in der Anfrage herab- und
heraufzusetzen.
Ja, aber ich will diese Ranking-Funktion ohnehin
nicht benutzen. Was ich an Deiner Stelle einbauen
würde, wäre eine eigene Ranking-Funktion. Ein Term
dieser Funktion wäre die Anzahl der Postings des
Autors in dieser Kategorie ... das hebt die Spezia-
listen heraus, das _muss_ eine gute Näherung sein.
* * ist ein Trunkierungsoperator.
Was heißt das genau?
Die Boole'sche Suche benutzt eine vereinfachte Art,
die Relevanz zu berechnen, die keine 50%-Schwelle
hat.
Relevanz interessiert mich im Moment überhaupt nicht.
Da traue ich meiner eigenen Kristallkugel mehr. ;-)
Suchen sind jetzt wegen optimierter
Suchalgorithmen bis zu 2 mal schneller.
Ja, das ist prima. Den Faktor 2 nehmen wie später mit,
wenn sich die Software installieren läßt.
Den Entwurf darauf aufzubauen, dafür ist es zu wenig.
Hast Du die 4.0 schon mal damit im Einsatz
gesehen? (Ich noch nicht, ich kenne nur die
Handbücher dazu.)
Wieso sollte das nicht gehen?
Habe ich das behauptet?
Das Produkt, für welches ich meine Suchmaschinen im
Büro schreibe, liefert eine 3.23-Datenbank mit aus -
mit der muß ich arbeiten, weil dort die Entitlement-
Daten drin stehen, gegen welche meine Suche ihre
Treffer filtern muß usw.
Und meines Wissens soll 4.0 irgendwann Ende dieses
Anfang nächsten Jahres Stable sein, dann sollte das
funktionieren.
Bis dann das Produkt unserer Schwesterfirma mit mySQL
4.0 läuft, wird es also Ende 2003. :-(
sehr gerne! Wenn ich helfen kann, aber wie Du
siehst kenn ich mich noch sehr wenig aus...
Du kannst auf jeden Fall mal eine Checkliste all
dessen machen, was die bisherige Suche kann, und Dir
rudimenär überlegen,
a) ob und wie es via mySQL implementierbar wäre und
b) wie wichtig das jeweilige Feature ist.
Kandidaten, die mir spontan Probleme bereiten würden,
sind:
1. Verwendung regulärer Perl-Ausdrücke in Termen.
(Das wird schwierig, aber vielleicht mit mySQL 4
möglich?)
2. case-sensitive Suche (finde ich wichtig).
3. Die Möglichkeit, Terme mit Suchbereichen einzugeben
(author:cheatah body:mailto).
Das ist machbar, erfordert aber eine viel genauerer
Analyse der eingegebenen Suchbegriffe - also: Arbeit.
id smallint(6) NOT NULL default '0',
Ich würde lieber 24 Bit nehmen als 6 Ziffern.
und wie nehem ich das? In welchem Format kann ich
das speichern? Udn wie muß ich dann schreiben?
im Bits Konvertieren???
Die genaue Notation habe ich nicht im Kopf - kannst
Du die (6) nicht einfach weglassen?
Ich meinte nur: smallint belegt doch wohl sowieso eine
bestimmte Anzahl bits - warum dann auf 6 Dezimalen
einschränken?
) TYPE=MyISAM;
Yep. (Das ist der Defaultwert bei mySQL.)
und soll auch das schnellste sein, oder?
Es ist der einzige, der FULLTEXT kann ... das ist eine
Erfindung des MYISAM-Tabellentreibers, nicht von mySQL.
a) mehr als einen Suchbegriff und
Das funktioniert doch schon! ODer meinst Du
Nur Datensätze, die _alle_ Begriffe enthalten?
Letzteres, ja.
Die Treffermenge _muß_ deutlich kleiner werden.
b) Phrasen
Das hat doch nur Sinn wenn der Index dieses
unterstützt, und das machen IMHO weder Version 3
noch 4
Eine Phrase läßt sich durchaus mit mySQL 3.23 lösen:
Zerschlage sie in all ihre 'Worte' (gemäß der Termi-
nologie von FULLTEXT), mache ein AND darüber, bete ein
bißchen, daß es _jetzt_ nur noch wenige Treffer sind,
und mache anschließend ein LIKE %phrase% über das
gesamte Posting!
Wenn Du die Treffermengen klein genug kriegst, wird
das funktionieren. Mit großen hast Du keine Chance.
(Deshalb ist mir das AND so unheimlich wichtig!)
gute Ranking-Funktion darauf anwenden kannst.
Stimmt, das hatte ich auch schon gedacht, das
Ergebinis in einen Array schreiben und den munter
sortieren!
Die Ranking-Funktion kann auch schon statisch beim
Import berechnet und in der Tabelle abgespeichert wer-
den. Stell Dir vor, diese Funktion wäre identisch
zur Anzahl der Postings des Autors in dieser Kategorie
zum Zeitpunkt der Aufnahme dieses Postings. Dann wäre
das einfach eine zusätzliche Spalte in Deiner Tabelle,
nach der Du die Treffer mit ORDER BY auslesen kannst.
Der Phrasenfilter wird etwas schwieriger ...
Wie soll das auch gehen?
Siehe oben.
Schau Dir erst mal mit EXPLAIN an, wie die
Datenbank Deine Statements überhaupt umgesetzt
hat.
Wird der FULLTEXT-Index wirklich verwendet?
Jetzt kann man die Ausgabe von EXPLAIN und die
Query selbst sehen!
Fein - das hilft allen Testern, zu sehen, was passiert.
Viele Grüße
Michael