Hi Tom,

Wie wäre es, wenn die Postings, die man direkt aufruft
als statische HTML-Seiten gespeichert würden (weil am
meisten gelesen) und der Schwanzabschneider (so heisst
das Ding doch) die Daten in XML kovertiert, sobald diese
ins Archiv übergehen.
Die HTML-Dateien könnten danach gelöscht werden. Die CPU-
Last könnte so afaik ein gutes Stück gesenkt werden.

Ja - das wäre in der Tat eine rein performance-orientierte Implementierungsform. Die dauerhafte Speicherung der HTML-Dokumente wäre eine Caching-Maßnahme, um Lesezugriffe gegenüber Schreibzugriffen zu bevorzugen.
Und die ursprüngliche Implementierung funktionierte auch tatsächlich so, daß die Postings in Form von HTML-Dokumenten abgelegt wurden.

Das Problem ist nur: Ein Programm (nämlich der Poster) muß auch in diesem Fall dynamisch HTML-Dokumente analysieren, weil sich der Inhalt nicht nur einer, sondern vieler (!) HTML-Dokumente durch ein Posting ändert.
Ein Link auf ein neues Posting ist in jedem übergeordneten Posting des gesamten Threads drin.
All diese Dateien müßten während der Änderung gesperrt werden.
Und das Analysieren der HTML-Dokumente wäre auch nicht beliebig schnell.
Ja - das Lesen würde schneller. Dafür würde das Posten langsamer. Und das ist nicht der einzige Nachteil ...

Stell Dir mal vor, Du willst das optische Erscheinungbild des Forums (bzw. des gesamten Portals) jemals ändern.
Wenn die Forums-Postings als HTML-Dokumente gespeichert sind, dann ist das gesamte Layout zweihunderttausendmal fest eingebrannt. Möchtest DU das ändern?
Die Verwendung von XML und die dynamische Anzeige-Aufbereitung erlaubt es dagegen, die optischen Elemente dynamisch aus einer (!) Konfigurationsdatei zu laden - das Forum könnte 'on the fly' geändert werden, im laufenden Betrieb und ohne jedes Problem mit vorhandenen Datenbeständen.
Das ist einer der Vorteile der sauberen Trennung zwischen einer internen (XML, Datenbank, ...) und einer externen (HTML) Darstellung.

Viele Grüße
      Michael