nicht angemeldet
Hi!
also erst mal vorweg:
- Das, was Du machst, _ist_ vernünftig.
schön zu hören :)
- 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!
Daß die Ranking-Funktion von mySQL nicht zur
Aufgabenstellung paßt, hast Du ja selbst gesehen.
ja
Alternative: Laß Dir von Christian die existierenden
Indexdateien geben, damit Du erst mal die Datenbank
schnell kriegst.
Den Parser kannst Du hinterher immer noch schreiben.
Naja, jetzt habe ich das komplette Archiv 2002, das reicht zum probieren aus, denke ich!
Ich habe jetzt 3 Stunden lang versucht MySQL 4 zu
installiern, was an sich nicht schwer war,
Dein Modell funktioniert mit mySQL 3.23 gut genug.
Mach es erst mal damit.
Ja mir bleibt eh nicht anderes übrigm da ich 4.0 einfach nicht mit PHP ans laufen bekomme. Vermutlch ginge es mit PERL, aber ich brauch die DB nicht nur für diese Suche, und überall anders verwende ich noch PHP.
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.
MATCH ... AGAINST wird folgende Boolesch Operatoren unterstützen:
* +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.
* < und > können benutzt werden, um die Wortgewichtung in der Anfrage herab- und heraufzusetzen.
* ~ kann benutzt werden, um einem 'Rausch-Wort' ein negatives Gewicht zuzuweisen.
* * ist ein Trunkierungsoperator.
Die Boole'sche Suche benutzt eine vereinfachte Art, die Relevanz zu berechnen, die keine 50%-Schwelle hat.
Suchen sind jetzt wegen optimierter Suchalgorithmen bis zu 2 mal schneller.
denn gerade für Volltext-Suche ist die 4er erheblich
besser.
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? Unter Windows habe ich eien ganze Zeit mit 4.0 udn PHP gearbeitet, wobei die API hier noch einige Schwachstellen hatte, lag aber größtenteils an PHPmyAdmin und dem noch"experimentellen" Apache2 Support von PHP. Und meines Wissens soll 4.0 irgendwann Ende dieses Anfang nächsten Jahres Stable sein, dann sollte das funktionieren. Und wo wenn nicht bei sowas kann man beta-Versionen verwenden und von derartig großen Vorteile profitieren!
Dann stimmt etwas nicht. Der Trick der Indexe ist doch
gerade, daß es _nicht_ langsamer wird.
Das Problem ist, das andere Prozesse zur selben Zeit viel Last gekostet haben...
Die Datenbank lasse ich jetzt auch mal online, würde
mich mal interssieren was Ihr davon haltet.
Die Idee ist richtig, und Du wirst dabei wertvolle
Erfahrungen sammeln, die Du mit Daniela austauschen kannst.
sehr gerne! Wenn ich helfen kann, aber wie Du siehst kenn ich mich noch sehr wenig aus...
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???
topic varchar(20) NOT NULL default '',
title varchar(100) NOT NULL default '',
Bei beiden kann Dir die Forum-Software die exakten
Maximalwerte sagen.
Stimmt. Ich würd egerne CHAR nehmen, aber das geht nicht, da Text ein Feld mit variable Länge ist.
body text NOT NULL,
Wie lang ist "text"?
Gäbe es etwas Kleineres, das 12 kB aufnehmen kann?
Text hat L+2 Bytes, wobei L < 2^16, sind max 64 kB
darunter gibt es nur noch TINYBLOB, TINYTEXT L+1 Bytes, wobei L < 2^8, aber das ist wohl etwas wenig!
time int(10) NOT NULL default '0',
Gute Idee - ich mag das, auch wenn mySQL dafür wahr-
scheinlich proprietäre Datentypen hat.
Ja, ich könnte das in eien Timestamp oder Datetima Spalte schreiben. Wobei das erheblich mehr Daten sind, die ich nicht wirklich brauche und die nur Performanc und Hauptspeicherplatz kosten!
FULLTEXT KEY body (body,topic,title)
Wie ist es mit den anderen Spalten (author)?
Naja, hast Recht.
) TYPE=MyISAM;
Yep. (Das ist der Defaultwert bei mySQL.)
und soll auch das schnellste sein, oder?
Die Gewichtung ist aber nicht das gelbe vom Ei.
Das ist noch viel zu unflexibel.
Vergiß die Ranking-Funktion. Bestimme erst mal einen
schnellen Zugriff auf alle legalen Treffer für
a) mehr als einen Suchbegriff und
Das funktioniert doch schon! ODer meinst Du Nur Datensätze, die _alle_ BEgriffe entahlten?
b) Phrasen
Das hat doch nur Sinn wenn der Index dieses unterstützt, und das machen IMHO weder Version 3 noch 4
Danach kannt Du immer noch eine eigene Ranking-Funk-
tion auf die gefundenen Treffer anwenden, wenn es denn
sein muß. Eine Ausgabe, die umgekehrt nach Datum sor-
tiert herausgespult wird wie bisher, ist auch nicht so
schlecht als erste Version. Wenn Deine Anwender mehrere
Suchbegriffe eingeben dürfen, die Du mit AND verknüpfen
kannst, wird die Treffermenge so klein, daß Du eine
gute Ranking-Funktion darauf anwenden kannst.
Stimmt, das hatte ich auch schon gedacht, das Ergebinis in einen Array schreiben und den munter sortieren!
Der Phrasenfilter wird etwas schwieriger ...
Wie soll das auch gehen? Das müßte man komplett anders implementieren, wobei, vielleicht gejt es ja mit meinem instr(), wobei das jeglicher Optimierung spotten würde!
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! Das hilft Dir vielleicht das besser zu verstehen. Da sieht man nämöich, das ich im "standardmodus" mit "Rabking" gar nichts an einer originalen Fulltext-Query verändere. Vielleicht ist der begriff auch noch faslch gewählt, da kommt ja eh nur "Quatsch" zurück!
Danke vielmals für Deine ausführlichen Antworten! Zu den anderen schreibe ich später noch was.
Grüße
Andreas
PS: Das ist jetzt das 2. mal das ich mit Mozilla nicht mehr weiterkomme, da ließ sich einfach nichst aus der ZWischenablage in das Textfeld kopieren...