Hallo Andreas,

Was ich jetz imme rnoch nicht genau verstanden habe -
erstellt FULLTEXT jetzt eine interne Tabelle wie
oben, oder einen B-Baum?

Wo ist der Unterschied?
Ich dachte immer ein Binärer Baum würde bei einem Wort
anfangen und sich dann weiter verzweigen, wie man das
ganze "statisch" speichern soll ist dann so eien Sache die
ich noch nicht wirklich verstanden  habe, aber das soll
wohl gehen. Eine Tabelle wird ja nur linear durchsucht.

Wer sagt das? Eine Tabelle kann auf viele verschiedene Arten
durchsucht werden, abhaengig von ihren Indizes und den
gestellten Queries.

Aber ich verstehe inzwsichen doch den Vorteil, denn die
Tabelle enthält zwar alle Wärter der indizierten
Spalte(n), aber jedes nur einmal. Somit spart man durchaus
Zeit. Nur braucht manb dann ncoh die Information, in
welchem Datensatz das besagte Wort jetzt vorkommt, udn
hierzu braucht man IMHO eine 2. Tabelle in der der eine
Verknüpfung zw. Wort und Posting_IDhergestellt, wird.

Korrekt. Tatsaechlich ist es sinnvoll, das mit 3 Tabellen zu
loesen, da eine n:m-Beziehung vorliegt:

Postings        Woerter
   |     Nodes     |
   |       |       |
   +-------+-------+
     1:n       n:1

Jedem Posting sind n Nodes zugeordnet, jeder Node ist 1 Wort
zugeordet.

Wenn
man nur eine  einzige TAbelle verwenden würde, dann müßte
man in die eine Tabelle genausoviele Datensät7ze schreiben
wie die zu indizierende Spalte Wörter enthält,

Korrekt.

und nicht
jedes einmal, sondern so oft es insgesamt vorkommt, mit
einer 2. Spalte Posting_ID.

Warum sollte man Woerter doppelt speichern? Du kannst
stattdessen die Wertigkeit mitspeichern, in einer weiteren
Spalte.

Und ist das wichtig?
Dachte ich...

Der Fulltext-Index ist eine Blackbox. Wie genau er
funktioniert, ist doch eigentlich unwichtig.

Das heisst, dass *nicht* der komplette Index im Speicher
gehalten wird, sondern nur teilweise im Speicher
behalten werden braucht.
aber welcher Teil?

Der Teil, der gerade nur benoetigt wird.

Woher weiß ich vorher was der User als nächstes in der DB
sucht?

Gar nicht. Warum solltest du das wissen muessen? Behalte die
durchschnittlich am meisten gebrauchten Teile permanent im
Speicher und gut.

Denn wie schnell ist nochmal eine IDE Leitung?

Kommt darauf an, welcher IDE-Standard. UDMA133 kann bis
zu 133MB/s transferieren.
Theoretisch, praktisch aber nur die von mir genannten gut
50 MB/sek.

Und wie kommst du auf solche Aussagen? Kannst du die belegen?

Warum sollte sie? Dateien sind nicht sequentiell. Man
darf durchaus auch nur 10 Byte in der Mitte auslesen,
oder 100 Byte am Anfang.
OK, aber woher weiß ich jetzt welche 10 Byte ich genau
raushole?

Das ergibt sich aus deiner Datei-Struktur.

Wenn ich den Index nicht im Speicher habe, muß ich doch
bei einer Anfrage erstmal den kompletten Index in den
Speicher laden, um dann mit Hilfe des Index(denn ich
einmal komplett parsen muß) den Teil der Tabellendatei zu
ermitteln, den ich jetzt gut gebrauchen könnte, oder?

Warum?
Nehmen wir mal einen Baumartigen Index. Das Dateiformat kann
man so anlegen, dass man den Baum direkt anlegen kann. Wenn
ich jetzt dem Pfad folge, hole ich immer nur genau die Teile
von der HD, die ich als naechstes brauchen werde. Das kann
ich z. B. erreichen, indem ich bei jedem Knoten mitspeichere,
wo die naechste Node zu finden ist. Das kann im einfachsten
Fall ein Pointer sein und im schlimmsten Fall ein Dateiname
mit einem Byte-Index.

Wozu braucheich einen Volltext-Index bei Kategorie?
Da habe ich ja feste Strings die ich vergleiche
kann. Ich könnte sogar die Strings in Zahlen
umfandeln, halt für jede Kategorie eine Zahl das
dürfte nochmal helfen!

Unwahrscheinlich. Wenn, dann nicht merkbar.
String-Indizes sind im Normalfall Hashing-Indizes, und
die sind nicht wirklich langsamer als Zahlen-Indizes.
Ja? Das hat mir jemand mal ganz anders erklärt, dass ein
String-Vergleich vor allem in größeren Tabellen erheblich
länger dauert als ein Integer-Vergleich.

Ein Vergleich durchaus, ja. Aber Hashing basiert nicht auf
Vergleichen. Es wird eine Hash-Summe erstellt, durch die ein
direkter Lookup in der Tabelle gemacht werden kann. Natuerlich
kann ein Hashing-Algorithmus bei einer endlich langen
Schluessellaenge nicht perfekt sein, aber die Zahl der
Dupletten haelt sich in Grenzen.

Gruesse,
 CK