Hi,

was macht ihr eigentlich alle noch hier? Keine Einladung? ;-)
(Bevor jemand dumme Fragen stellt: ich sollte ein Roastbeef machen, das muß noch etwas Zeit im Ofen verbringen. Dann bin ich auch weg.)

mehr Platz als die Schroeplsche Volltextdatei???

Ist doch auf voellig logisch. Es fallen viel mehr Metadaten an.

Ähm, eigentlich nicht wenn man zweistufig arbeitet...Ihr habt aber wohl ein anderes Konzept.
Was sind hier Metadaten? Speichert ihr zu jedem _Wort_ Autor, Datum, Link, etc als Strings ab? Es reicht doch eine Referenz aufs Postinginfos in einer Tabelle abzulegen, soviel Zeit kostet das doch wohl nicht.

Aber Raum und das ist die Absicht. Hier wird der übliche Handel getrieben: Platz gegen Geschwindigkeit. Nur reicht jetzt dummerweise der Raum nicht und das DB-Konzept muß geändert werden. Das man da erstmal keine Lust mehr hat, wenn man das feststellt finde ich durchaus verständlich ;-)

Aber nebenbei: selbst so ein einfacher Index, wie er Dir vorschwebt verbrät ordentlich Platz:
Gesetzt den Fall, das nach Abzug aller Stopwörter und sonstigem Mist alle Wörter (= mit Leerzeichen/Newline getrennte Buchstabenanhäufungen) niedergemacht (lowercase()) werden, kommen da bestimmt so um die 100.000 Worte zusammen. Alle komprimiert (32Bit reicht da völlig) und mit einem Pointer (auch mal von 32Bit ausgegangen) auf die eigentlichen Metadaten versehen macht das 800.000 Oktets. Overhead der Hashtable/des Baumes gar nicht mitgerechnet.
Also alleine schon ein knappes Gig für die platzsparendste(!) Lösung! Was da bei einer auch nur _etwas_ mehr auf Geschwindigkeit ausgelegter Lösung zusammenkommt muß ich ja hier nicht mehr vorrechnen, oder? ;-)
Dazu ist der Komfort des oben beschriebenen Primitivstindexes nicht sehr sonderlich, da würden sich mit Sicherheit alle beschweren.

so short

Christoph Zurnieden