Hallo!

Tabelle worte:
  wort_ID
  wort_STRING

Tabelle postings
  wort_ID
  posting_ID

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

JOIN kostet Zeit. Muß das sein?

So wäre es jedenfalls erstmal schön relational, aber mir ist bewußt das schön nicht unbedingt = schnell bedeuten muß. Auf der anderen Seite muß man überlegen das durch weniger Daten die einzelnen Anfragen schneller sind, als wen viele unnötige Daten die "Leitungen und den RAM verstopfen".

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!

Kann man eine Baumstruktur nicht fest in irgendeiner Datei speichen, das nur noch der fertige Baum geladen werden und durchsucht werden muß

Sicher. Das ist dann allerdings extrem änderungsunfreundlich.

denn das erstellen des Baums wird vermutlich ähnlich lang dauern wie das erstellen des Fulltext-Index!

Das kommt darauf an, wie Hashes implementiert sind. Ich habe irgendwas vage in Erinnerung, daß man komplexe Datenstrukturen a la Hash in Perl direkt speichern und wieder laden können soll ... aber von konkreten Programmiersprachen habe ich ja bekanntlich keine Ahnung.

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!

Zumindest in meine Tests, wenn der Index im Cache liegt(die SQL-Abfrage kann in MySQL 3.23 noch gar nicht gecached werden!) wird das sehr schnell, sobald der komplette Index auch der Festplatte nach unschärferen Wörtern durchsucht wird wird er langsam.

Sorry, das ist mir nicht konkret genug. Was heißt "unschärfere Wörter"? Dort kann die Ursache des Problems stecken.

Sorry, faslch ausgedrückt, ich meien so allgemeine, oft vorkommende Begriffe wie HTML oder Javascript(übrigens das hier am meisten vorkommende mit dem allgemeinen Thema Webdesign zusammenhängende Wort)

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

Du bekommst nicht alle Zugriffe schneller. Du bekommt Zugriffe mit wenigen und gut projezierenden Zugriffen sehr viel schneller, während Zugriffe mit vielen und/oder schlecht projezierenden Suchbegriffen bei Dir variabel viel kosten, im Original aber alles gleich viel.

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.

Deshalb braucht das Ding ja auch eine Aufgabenstellung.
_Ich_ weiß genau, warum ich Deine Implementierung lieber bedienen wollen würde als meine: Weil ich gut projezierende Suchbegriffe kenne. Deine Implementierung ist sehr viel expertenfreundlicher - wer sie richtig bedient, kann damit Quantensprünge erreichen.

Naja, davon sehe ich nmich noch weit entfernt, ich erlebe zwar Quantensprünge, eber eher von "unhaltbar lahmarschig" nach nur noch "nervig langsam" ;-)

Meine Implementierung ist für alle Anwender fast gleich langsam ... wobei auch dort die Verwendung von spaltenbezogenen Suchbegriffen etwas bringt, aber keine großen Faktoren.
Und nun überlege Dir, für welche Zielgruppe _Du_ implementieren willst ...

Oder noch krasser: Glaubst Du, aus der Eingabe der Such-Maske (blacklist, Zahl der Suchbegriffe, etc.) schließen zu können, ob der lineare oder der logarithmische Ansatz schneller sein wird? Du könntest ja auch beides implementieren und dynamisch entscheiden, was Du wirklich tust ... jetzt denk Dir noch ein bißchen KI dazu, also eine lernfähige Maschine ...

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)]

Durch das vorherige Sortieren der Suchbegriffe kann ich das schonmal erheblich besser in meine Suche einbauen. Dann prüfe ich die Worte im Suchstring auf Vorkommen, das seltenere wird dann zuerst in die SQL-Query geschrieben. Naja, und da könnte ich jetzt auch ansetzen und hier verschiedene Suchpfade erstellen usw.

Wie ist das eigentlich bei PostGreSQL, gibt es da ein Äquivalent zum MySQL Fulltext-Index, oder bräuchte man hier die Version mit den/der eigenen Tabelle?

Viele Grüße
Andreas