Hi Andreas,
schreib mal die Art der Relation dazu (1:1? 1:n? m:n?), dann versteht man es besser.
damit hab ichs nicht so, bin halt leider kein Relationaler DB-Experte ;-)
Aber ich versuchs trotzdem mal:Tabelle worte: Tabelle wort_in_postings: Tabelle postings
+--+ ID(primary) +------+ wort_ID +------+ ID(primary)
| + wort_STRING | +--+ posting_ID | + Titel
| | | | + Autor
| | +--------------------+ + Timestamp
+------------------------+ n:1 + ...
1:n
ups - in Verdana kann ich davon nichts lesen.
Innerhalb der Textarea dann schon: Ah, ja.
Die Tabelle wort_in_postings ist diejenige, welche von FULLTEXT quasi implizit erzeugt wird.
Dann weiß ich allerdings nicht, warum Du zwischen wort_ID und wort_STRING noch einen JOIN machen willst, wo Du doch auch beide Tabellen über die ID verschmelzen kannst. Die ID muß in _dieser_ Tabelle nicht unique sein - sie muß nur einen unique-Zugriff in postings erlauben.
Das finde ich nicht schlimm, wenn anschließend ein daemon diese Struktur sehr lange im Hauptspeicher hält. Genau auf diesem Prinzip basiert das neue Forum ...
Das wäre aber dasselbe als wolle ich den kompletten MySQL Fulltext-Index im RAM halten, und das war schon etwas viel!
Genau. Und FULLTEXT würde von der Datenbank sogar noch seitenweise ein- und ausgelagert ... das macht Perl mit seinem Hash vielleicht auch, aber ich fürchte, Du mußt die Daten bei der Perl-Lösung wenigstens einmal komplett "durch den Speicher schießen", bevor sie in der paging area landen.
Es muß nicht alles im RAM liegen.
Aber _das_ macht den entscheidenen Unterschied!
Das glaube ich nicht. So viele Zehnerpotenzen schneller als eine gute Festplatte ist der RAM nun auch nicht.
Es würde ja eine 10er Potenz reichen die Wartezeit von 5 auf 0,5 Sekunden zu senken, das würde mir ja schon reichen!
Wenn Du den Faktor 10 zwischen RAM und Platte damit bezahlst, den kompletten Index und damit tausendmal so viel wie notwendig einlesen zu müssen, dann hast Du nichts gewonnen.
Sorry, das ist mir nicht konkret genug. Was heißt "unschärfere Wörter"? Dort kann die Ursache des Problems stecken.
Sorry, falsch ausgedrückt, ich meine so allgemeine, oft vorkommende Begriffe wie HTML oder Javascript (übrigens das hier am meisten vorkommende mit dem allgemeinen Thema Webdesign zusammenhängende Wort)
Genau. Und die sind so unscharf, daß sie auf die schwarze Liste gehören.
Es reicht, wenn pro Zugriff nur eine kleine Menge an Seiten ins RAM eingelagert werden müssen. Und Baumstrukturen sind ein Mittel, dies zu erreichen: Wenn die Komplexität bei 100000 Postings von linear auf logarithmisch sinkt, kannst Du einen Faktor von knapp 1000 an Performance gewinnen. (100000 -> 17 * 7)
bisher konnte ich davon herzlich wenig spüren. viel schneller als die bestehend Archivsuche wurde ich nicht, eher langsamer
Bei guten Suchbegriffen bist Du deutlich schneller geworden, dachte ich? Oder sind es immer erst mal 5 Sekunden, egal was Du suchst?
Ja, aber Zeiten wie 5 Sekunden kann ich einfach nicht tolerieren finde ich! Darauf habe ich es bis jetzt senken können z.B., bei "javascript opener", Da brauchst Du nichtmal 1 Sekunde für.
Bei dieser Anforderung ist "opener" der 'gute' Suchbegriff, der die Sache schnell macht. Und da er nicht auf der schwarzen Liste steht, im Gegensatz zu "javascript", weißt Du auch, wie Du diese beiden Begriffe zu sortieren hast ...
Als erstes würde ich das Menbü schonmal anbders aufbauen als das bestehende, kannes zwar leide rnicht zeigen, aber mal grob:
[ENGABE SUCHBEGRIFF(E)]
[SELECFELD: Kategorie( wie im Forum)]
[EINGABEFELD: Autor]
[OPTIONSFELD: Auflistung chronoligisch/ranking]
[CHECKBOX: alle Suchbegriffe müssen enthalten sein (ist nämlich eh in 90% der Fälle gewünscht)]
Du bist Dir bewußt, daß dies (über eine entsprechende Notation im Eingabefeld) alles bereits mit der bestehenden Suchfunktion möglich ist? (Ausgenommen die Checkbox - die ist bisher auf "aktiv" festgebrannt.)
Durch das vorherige Sortieren der Suchbegriffe kann ich das schonmal erheblich besser in meine Suche einbauen.
Bist Du Dir bewußt, daß Du dann mehr als einen FULLTEXT-Index verwenden wollen wirst?
Dann prüfe ich die Worte im Suchstring auf Vorkommen, das seltenere wird dann zuerst in die SQL-Query geschrieben.
Wenn Du mit derartig komplexen Möglichkeiten anfängst, dann wird die Sache mit der Generierung einer guten Query sehr viel anspruchsvoller. Denn eine Blacklist für Suchbegriffe hat eine ganz andere Wirkung als eine Blacklist für Autoren etc.
Viele Grüße
Michael
T'Pol: I meant no insult.
V'Lar: Of course not. You're simply speaking your mind ... as you always have.