Hi Michael,

Aber Geschwindigkeit war auch weniger das Argument, als Konsistenz der Schnittstelle. Bis jetzt ist das ein ziemliches Durcheinander. (Wovon ein Großteil auf die kaputten alten Archive entfällt)
Deshalb hatte ich mir gedacht: wenn schon eine DB da ist, warum da überall patchen, verlinken, rumpusseln, wenn es evt einfacher wäre, _alles_ in die DB zu packen.

wenn es Dir nur um die (wünschenswerte)

(Aber leider so verdammt arbeitsintensive)

Normalisierung des Datenbestandes geht, ist eine Normalisierung auf das bestehende Datenformat (XML) nicht schlechter (sondern eher besser) als eine Normalisierung auf ein neu zu erfindendes Datenformat, an welches sämtliche bestehende Software erst mal angepaßt werden müßte.

Was hat denn das Datenformat mit der Datenbank zu tun?
Ja isses denn? Bloß weil ich jemandem hier einmal angeboten habe, sich in SQL auszudrücken? ;-)

Aber eben jene Normalisierung bzw reperatur der alten Archivdaten scheint mir dann doch vordringlichste Arbeit zu sein.

Und das Problem der Normalisierung besteht sicherlich nicht darin, HTML syntaktisch nach XML zu konvertieren, sondern - wie Du wissen solltest - die jeweils unterschiedlichen Semantiken aufeinander abzubilden ... was insofern besonders lästig ist, daß Informationen, für die im heutigen XML-Format ggf. Platz (und Bedarf!) wäre, im HTML-Format noch fehlten. Selbst wenn das Forum also syntaktisch normalisiert wäre, würde es semantisch immer noch unterschiedliche Qualitäten aufweisen ... was lästig ist, wenn man sich bei der Implementierung z. B. intelligenter Zugriffsverfahren auf eine einheitliche Qualität verlassen möchte.

Tja, das so eine Umstellung nie so _ganz_ ohne Verluste abgeht ist leider normal.
Ein kleiner Hinweis bei der Anzeige sollte darüber hinweghelfen.

Ach, ich glaube ich schließe mich so langsam aber sicher der Meinung des Kollegen Rautenberg an: das ist alles einfach zuviel Aufwand für zuwenig Erlös.

Ich auch. Deshalb wäre mein erstes Ziel bei einer solchen Aktion, unter vollständiger Beibehaltung der bestehenden Software eine "Qualitäts-View" über das Archiv zu legen, die aus nichts anderem bestehen würde als aus einer Teilmengenbildung.

Idee zur Implementierung zur Hand?
Vor allem: mit dem kläglichem Versagen des "Archiv" Buttons vor Augen.

Aus technischer Sicht: es ist eine zusätzliche Information zu speichern. Die existiert dann aber erst ab dem Zeitpunkt des Einbaus. Was ist mit dem Rest? Ein leerer Container müßte eh aufgrund der angestrebten Normalisierung in die alten Dateien eingebaut werden. Also könnte ein Aufruf, der über die Suche erfolgte ebenfalls solcherart Voting anbieten. Das könnte dann wie unten beschrieben einfach gesammelt und hin und wieder indexiert werden.
Aufwand wäre recht gering. Erfolg ebenfalls?

Jede darüber hinausgehende redaktionelle Verschlagwortung etc. birgt erhebliche zusätzliche Probleme in sich, die eher im organisatorischen Bereich liegen als in der entsprechenden Software-Umsetzung.

Soviel zum Stichwort:"redaktionell" >;->

Der bestehende (derzeit einmal täglich nachts laufende) Archiv-Indexer würde in einer entsprechenden Variante darauf angepaßt werden müssen, diese "Mengendefinition" (die aus einer simplen Liste von Posting- bzw. Thread-IDs bestehen könnte - die Suche "denkt" in Postings, nicht in Threads) zu lesen, die entsprechenden Postings aus dem Forum zu fischen und zu indexen und eine Indexdatei im bekannten, such.pl-kompatiblen Format zu erstellen ... dies wäre in wenigen Stunden zu realisieren, inklusive der Einbettung dieser neuen Indexdatei in das Such-Formular.

Ja, das wäre recht einfach implementierbar.
Bleibt die Frage: bringt das was? Außer der Fingerübung?
Oder wäre es evt sinnvoller beim "Neuen Thread eröffnen" Formular die Suche an prominenter Stelle anzubringen? ;-)

so short

Christoph Zurnieden