Hi Rolf
Schlüsselwort -> (*posting1, *posting2, *posting3, ...)
wäre m.E. speichereffizient und ausreichend.
Die Literatur zur 1. Normalform erklärt dir hinreichend, warum man sowas _niemals_ tun sollte. Allgemein würde ich auch sonst Datenbankliteratur empfehlen, auch zum Thema Joins. Achja, Datenbanken cachen durchaus auch. Wenn gewisse Dinge oft gebraucht werden, liegen sie also sowieso im Ram.
Zusätzlich noch jeweils die erste Spalte und die erste Zeile mit den Postings resp den Schlüsselwörtern drin.
In der Betrachtung kann man IMHO diese ruhig Unterschlagen (linear statt quadratisch).
Ehm, nein, kann man nicht, ich würde durchaus mit einigen Megabytes mehr rechnen.
verstehe ich nicht, aktuell reichen 32bit locker aus um die Postings (zumindest eines Jahres) zu nummerieren.
Wir haben aber nicht nur die Postings. Zudem nimmt die Zahl der Postings aktuell nicht linear zu sondern eher in Richtung exponentiell.
- Die meisten eine ausführliche Anzeige wollen, also sowieso auf die Platte zugegriffen wird.
Nein, diese Information ist direkt in der Datenbank verfügbar.
Das zurückführen eines Wortes auf seine lower()-Variante kann man übrigens auch als primitive und effiziente Hashfunktion interpretieren.
Aha? Mir wäre neu das dabei eine Zahl herauskommt, die entweder einen Index in einem Array darstellt oder aber direkt eine Speicheradresse.
wenn wir die häufigsten 65536 Wörter des Archivs (ohne Stoppwörter) in einen optimierten² RAM-Hash legen, wäre das bereits sehr effizient und würde auch bereits mit "normaler" Hardware funktionieren.
Gerade nach den häufigsten Wörtern zu suchen, ist aber nicht sinnvoll. Möglichst gute Treffer erzielt man mit spezifischen Suchwörtern.
Nur in dem Fall, dass eine Dublette eines selteneren Wortes vorliegt müßte dann ein Plattenzugriff erfolgen. In den 65536 zugehörigen Files könnten dann die Dubletten wieder organisiert sein (eventuell wieder Hashes oder Binärbaum oder ne simple Liste).
Wozu zugehörige Files? Du willst aber nicht pro Wort in dem Hash einfach auf ein File verweisen wo eine Liste aus den möglichen Postings drin steht? Dazu brauche ich keinen Hash, dazu reichen Namenskonventionen.
Plattenzugrife müssen in der Suche sowieso erfolgen, die paar mehr die nur im Falle seltener Wörter vorkämen fallen kaum ins Gewicht. Für die Belange der Archivsuche reicht das IMHO allemal, und man ist von Hardwareanbietern unabhängig.
Erklär doch mal das Konzept was du da machen willst. Was ich mir aktuell darunter vorstelle, klingt sehr sehr langsam und unsinnig, deswegen denke ich, dass da doch das eine oder andere Missverständnis liegt.
Gruss Daniela