nicht angemeldet
Der Admin dort kennt sich mit dem Datenbankzeugs nicht so aus, gibt er offen zu. Wenn wir also herausfinden koennen, dass es eine Moeglichkeit gibt, mSQL so zu installieren oder zu konfigurieren, dass man mit einer untergeordneten User-Kennung da ran kommt, waere er durchaus bereit, uns eine mSQL-Loesung basteln zu lassen ...
Ich habe das starke Gefühl, daß hier zuerst über den Algorithmus diskutiert wird, ohne über die Dienstleistung nachzudenken.
Wieviel vom bisherigen Suchverfahren soll denn aufgegeben werden? regular expressions mit einer SQL-Datenbank? Volltextsuche mit einer SQL-Datenbank? Ich sehe irgendwie keine auch nur vage Ähnlichkeit zu dem bestehenden Suchverfahren.
Gerade bei regulären Ausdrücken nützt uns die gesamte Datenbank inklusive Indexbäumen nichts, und auch "Volltext" und "DB-Index" widersprechen einander m. E. ziemlich fundamental.
Stell Dir einfach vor, ein Indexeintrag müßte so lang werden können wie ein komplettes Posting - wie groß würde da wohl der Index werden, wenn er auch noch *jeden* Teilstring enthalten sollte? (Denn tut er das nicht, dann muß er wieder linear durchsucht werden, und die ganze schöne logarithmische Suchdauer ist beim Teufel.)
Das riecht nach exponentieller Größe (es wird ja einfach Zeit mit Platz erkauft), und das halten wir bei diesen Datenmengen nicht aus. Wir brechen ja schon unter einer linear wachsenden Datenmenge zusammen.
Wieviele Gigabytes darf unsere mSQL-Datenbank denn auf dem Server belegen?
Mir ist das Problem der wachsenden Datenmenge bewußt. Aber "SQL-Datenbank" ist kein Zauberwort, das die Datenmenge etwa kleiner machen würde, sondern nur ein Werkzeug zur Umsetzung einer bestimmten Strategie.
Bei einem Schlagwortindex würde ich eine relationale Datenbank prima finden, das hatte ich ja schon geschrieben. Aber bei einer Volltextsuche ... hm ...
Wenn schon eine Diskussion, dann würde ich diese über Ziele führen wollen und nicht über Technologien. Beispielsweise: "Ist eine Suche nach Phrasen in einem Volltextindex das, was dieses Forum unbedingt braucht?" Wenn die Antwort darauf ein überzeugendes "nein" ist, *dann* könnten die Karten neu gemischt werden.
Lautet sie aber "ja" (und in der bisherigen Diskussion war dies der Fall!), dann würde ich darüber nachdenken, wirklich am Datenvolumen zu drehen.
Beispielsweise könnte man den Index genauso in mehrere Dateien zerlegen wie das Archiv in mehrere Verzeichnisse, und dann wäre es die Entscheidung des Anwenders, wieviele Kreuzchen er im Suchformular macht. Macht er zuviele, dann wird es halt wirklich langsam - und über einen geeigneten timeout-Wert im Webserver (!) wird die Suche dann halt abgebrochen werden. (Man könnte ein Verzeichnis für Indexdateien auf dem Server scannen, daraus diese Auswahlfelder im Formular dynamisch generieren, dabei die Größe des jeweiligen Indexes in MB einblenden und sogar jede Auswahl zurückweisen, bei der die Summe der gewählten Indexe 'zu groß' wird - sogar die zu erwartende Suchdauer für seine Auswahl könnte man dem Anwender via JavaScript vorher ausrechnen ... alles ist machbar.)
Eine Einschränkung auf z. B. den letzten Jahrgang des Archivs oder so ähnlich klingt zunächst mager, aber wenn dort Postings zu finden sind, die selbst wiederum Verweise auf ältere Archiveinträge liefern, reicht es ggf. halbwegs aus.
Das eigentliche Problem ist, daß sich die Fragen im Forum ständig wiederholen und das intellektuelle Wachstum des Archivs mit dem reinen Mengenwachstum nicht annähernd Schritt halten kann. Mehr und mehr ähnelt eine Suche im Archiv einer Suche im WWW, weil die Archiveinträge inzwischen ähnlich viel "Rauschen" wie beliebige WWW-Seiten enthalten.
Die Antwort auf dieses Phänomen im WWW ist der Katalog, also die manuelle Indexierung der 'wirklich wichtigen' Informationen. Das Gegenstück hierzu in SelfAktuell ist die Archiv-Auslese! Diese würde ich also pushen, also z. B. dort neue Themengebiete wie XML, WAP usw. zu eröffnen und entsprechende Redakteure anzusaugen versuchen. Das macht gerade bei einem Themenforum mehr Sinn als eine technische Lösung, um aus viel Masse mit wenig Qualität etwas herauszufiltern - im letzten Jahr ist das Verhältnis zwischen Qualität und Quantität ja eher ungünstiger geworden, wie vereinzelt von den Auslese-Autoren im Forum angedeutet wurde.
So viel künstliche Intelligenz, um Semantik automatisch filtern zu können, haben wir leider nicht - hätten wir sie, dann könnte nämlich auch schon der bestehende Indexer im Schwanzabschneider versuchen, zu entscheiden, ob ein Posting es wirklich wert ist, geindext zu werden. Und dann müßten wir an den Datenstrukturen gar nichts ändern, weil wir deren Wachstum in den Griff bekämen.
Hätten wir zuverlässiges 'Personal' in irgendeiner dauerhaften Form, dann würde ich darüber nachdenken, einen Index-Zensor einzuführen, also eine Person, die das Forum liest und 'Luft-Postings' als solche markiert. (Ein Dialog-Interface dafür läßt sich ja programmieren - das schreibt dann halt einen zusätzlichen HTML-Kommentar in die Posting-Datei rein.)
Der Indexer könnte anschließend automatisch erkennen, welche Einträge in den Index aufgenommen werden sollen und welche nicht (ins Archiv selbst wandern natürlich alle).
Allerdings: Das Forum komplett zu lesen ist inzwischen vermutlich ein fulltime-Job, zumal dieser sofort erledigt werden muß, weil der Schwanzabschneider derzeit fast schon täglich aktiviert wird. Und die Verantwortung dieser Person wäre auch keine geringe.
Eine rein technische Lösung weiterzuentwickeln ist natürlich andererseits auch nicht völlig verkehrt.
Nur so als Info: Seit gestern habe ich einen Indexer, der SelfHTML in das Format des Archiv-Index umsetzen kann. Ich kann also mit dem Archiv-Suchskript in SelfHTML suchen, wenn ich ihm die entsprechende Indexdatei angebe. (Und die Indexdatei von SelfHTML ist gerade mal 2.4 MB groß, die Suche geht also rasend schnell!)
Dasselbe gedenke ich für die Forum-Auslese zu bauen (deren Volumen - derzeit - noch viel kleiner ist - das bißchen Verzeichnistraversieren habe ich schon in einem anderen Skript vorliegen). Und auch über die SelfAktuell-Artikel könnte man "schnell mal drüberfahren" ...
Danach könnten wir als nächstes mal darüber diskutieren, ob
1. das bestehende Archiv-Suchskript einfach einen großen Index durchsuchen sollte, der aus den drei Teil-Indexen zusammengemischt wurde, oder
2. man im Such-Skript über radio buttons auswählen können sollte, worin man suchen will, oder
3. es mehrere Verweise auf mehrere Such-Skripte geben sollte, die den zu durchsuchenden Index als CGI-Parameter erhalten würden, oder
4. es zwei Indexe geben sollte (einen für das Archiv und einen für alles Andere), oder
5. whatever.
Das erste, was der Anwender eine Suchmaschine über SelfHTML übrigens lernen muß, ist, *viele* Suchbegriffe anzugeben, also sein Problem exakt zu beschreiben. Bei einem einzelnen Suchbegriff ist die Treffermenge angesichts des eigentlich kleinen Datenvolumens ungeheuer. (Kein Wunder, wenn man halt auch im geballten Wissen wühlt ...)
Der Nutzeffekt einer Suche nur genau in SelfHTML ist meiner Meinung nach gar nicht so überragend groß, denn das Werk ist derartig gut über Kapitel und Schlagworte navigierbar, daß der Leser auch so findet, was er sucht.
Was aber meiner Meinung nach wirklich etwas bringen wird, das ist eine Suche über SelfHTML *und* Forum-Auslese *und* SelfAktuell-Artikel - denn semantisch ergänzen diese drei Teile einander, ohne daß die Navigation dies bisher unterstützen würde. Es gibt beispielsweise in der Auslese zwar Verweise auf SelfHTML-Kapitel, nicht aber auf SelfAktuell-Artikel - damit gibt es keine gemeinsame Navigationswurzel außer der SelfAktuell-Startseite.
Und die erschlägt den Suchenden halt doch irgendwie mit der Menge ihrer Angebote, zumal die Menge der Artikel ja nicht kleiner wird.
Es ist halt die typische Portalseite - und die Anwender verhalten sich entsprechend: Sie nutzen den Dienst, den sie verstehen, und behandeln alles andere wie Werbung ... "Wieso Auslese lesen? Es gibt doch das Forum, und damit kann ich umgehen."