Hi Michael

Der Primärschlüssel liegt in jedem Fall über beiden Spalten

... weil der Zugriff in die zweite Schlüssel-Komponente schneller ist als ein Zugriff auf den Inhalt der tatsächlichen Zeile, ja?

Ehm, nein. Weil eine der beiden Spalten den Datensatz nicht identifizieren kann. Alternative wäre eben so ein ekeliges,
inhaltsleeres zusätzliches Feld.

Natürlich geht das zu Lasten des Festplattenplatzes da die vielen Wörter ja n-fach
gespeichert werden anstelle nur einen kleinen numerischen Key.

Wenn ich Dich recht verstehe, dann beschreibst Du dasselbe, was ich auch schon Andreas gegenüber diskutiert hatte: An dieser Stelle lieber etwas mehr Speicher verbraten als einen zusätzlichen JOIN zu investieren.

Ja und nein, ich schätze nicht, das der zusätzliche Join beim lesen so extrem ins Gewicht fällt. Es kommt ja nur ein Zusatzzugriff auf einen Teil des Primärschlüssels hinzu. Beim Schreiben macht es jedoch einen grossen Unterschied, ob ich
erst lesen muss ob es das Schlüsselwort schon gibt, dann wenn
es nicht existiert schreiben und dann meinen effektiven Verknüpfungseintrag machen muss. Kommt jedoch der Teilwortindex (von dir geklaut) ins Spiel, muss ich eh erst lesen ob es das Schlüsselwort schon gibt und wenn nicht, die einzelnen Teilwörter schreiben wenn noch nicht existent. Ok, von dem her gesehen ist das auch nicht nötig, und da ein Hashkey nach der Christian mehr oder weniger ins Wasser fällt...

Wobei, es wäre möglich den zu verwenden wenn defaultmässig die Suche nur auf komplette Worte geht und Prä- und Postfixsuchen beide über den Teilwortindex realisiert werden.

Gruss Daniela