Andreas Korthaus: FAQ mit verweisen auf Beitr㤧 im Archiv

Hallo!

Ich hoffe mal das es das noch nicht gibt ;-)

So viele hervorragende Postings liegen im Archiv, und viele Leute funden die aber nicht, sei es weil sie nicht die richtigen Suchbegriffe kennen, oder der Titel etwas irreführend war... Außerdem findet man unter 100en mittelmäßigen Beiträgen zu einem Thema vielleicht ausgerechnet nicht den einen brillienten!

Da könnte man sich doch mal überlegen, so eine Art FAQ zu erstellen, die dann jeweils auf den/die besten Postings oder Threads zu diesem Thema verweist. Ich stelle mir das so vor wie die Featured Artikel, nur das da keine extra Artikel geschrieben werden, sondern auf den/die besten Postings zu dem Thema verwiesen wird, vielleicht sogar noch auf einen passenden Featured Artikel wenn vorhanden. So käme man mit der Zeit an eine wahnsinns Wissensdatenbank, erheblich umfangreicher als die Featured Artikel. Bzw., die Wissensdatenbank ist ja da, aber man hätte eine bessere "Schnittstelle" als die leidige Suche ;-)

Da das alles nicht so einfach zu pflegen wäre, müßte man sich vielleicht überlegen, so wie früher "Zur Archivierung vorschlagen", sowas wie "für FAQ vorschlagen"... dann hätte man schon eine Vorauswahl und müßte das dann nur noch zuordnen.

Das hätte den Vorteil das die Suchfunktion entlastet würde und einige Fragen gar nicht erst im Forum gestellt werden müßten und das die Benutzer, vor allem Anfänger, einfacher an die Informationen gelangen.

Wie denkt Ihr darüber?

Viele Grüße
Andreas

  1. Hi,

    Ich hoffe mal das es das noch nicht gibt ;-)

    *mööök!*

    http://selfhtml.org/sfausles/

    Da könnte man sich doch mal überlegen, so eine Art FAQ zu erstellen, die dann jeweils auf den/die besten Postings oder Threads zu diesem Thema verweist. Ich stelle mir das so vor wie die Featured Artikel, nur das da keine extra Artikel geschrieben werden, sondern auf den/die besten Postings zu dem Thema verwiesen wird, vielleicht sogar noch auf einen passenden Featured Artikel wenn vorhanden.

    Wunderbar - ich danke dir für dein Engagement! Wenn du das ernsthaft machen willst, kommt sehr viel Arbeit auf dich zu :) Die Idee ist nicht neu (aber immer noch gut) und mittlerweile gibt's ja auch http://aktuell.de.selfhtml.org/tippstricks/. Dort gibt's schon einige Beiträge, die aus Postings hier entstanden sind.

    Da das alles nicht so einfach zu pflegen wäre, müßte man sich vielleicht überlegen, so wie früher "Zur Archivierung vorschlagen", sowas wie "für FAQ vorschlagen"... dann hätte man schon eine Vorauswahl und müßte das dann nur noch zuordnen.

    Tja, das wurde schon damals nicht oft in Anspruch genommen, leider.

    LG Orlando

    1. Hi!

      Ich hoffe mal das es das noch nicht gibt ;-)

      *mööök!*

      http://selfhtml.org/sfausles/

      Naja, so ein Name schwirrte in meinem Kopf, habe aber zum verrecken keinen Link dahin gefunden, oder bin ich total blind?

      Da könnte man sich doch mal überlegen, so eine Art FAQ zu erstellen, die dann jeweils auf den/die besten Postings oder Threads zu diesem Thema verweist. Ich stelle mir das so vor wie die Featured Artikel, nur das da keine extra Artikel geschrieben werden, sondern auf den/die besten Postings zu dem Thema verwiesen wird, vielleicht sogar noch auf einen passenden Featured Artikel wenn vorhanden.

      Wunderbar - ich danke dir für dein Engagement! Wenn du das ernsthaft machen willst, kommt sehr viel Arbeit auf dich zu :) Die Idee ist nicht neu (aber immer noch gut) und mittlerweile gibt's ja auch http://aktuell.de.selfhtml.org/tippstricks/. Dort gibt's schon einige Beiträge, die aus Postings hier entstanden sind.

      War mir nicht bekannt, dachte das seien alles extra formulierte Artikel. Und von wegen Arbeit, man könnte das ganze ja auch verteilen, s.u.

      Da das alles nicht so einfach zu pflegen wäre, müßte man sich vielleicht überlegen, so wie früher "Zur Archivierung vorschlagen", sowas wie "für FAQ vorschlagen"... dann hätte man schon eine Vorauswahl und müßte das dann nur noch zuordnen.

      Tja, das wurde schon damals nicht oft in Anspruch genommen, leider.

      Sicher, so ist das nunmal mit solchen Funktionen und er Allgemeinheit. Wenn denn mal die neue Version des Forums rauskommt, dann hat man ja vermutlich auch eine Art Rechtesystem, schon im allgemeinen Forum, nicht nur über einen speziellen Zugang. Somit könnte man einigen Usern die sich dazu bereit erklären und bekanntermaßen "viel Ahnung von allem" haben, ein etwas ausführlicheres "In die FAQ aufnehmen" anzeigen, evtl. mit Auswahl der genauen Kategorie + Unterkategorie und ggfs. Vergabe eines aussagekräftigeren Titels. Und dann dieses Posting direkt in den FAQ speichern, oder vielleicht von jemanden noch freigeben lassen, evtl. ganz vielleicht noch eine Möglichkeit etwas am Text zu ändern, das sich aus dem einen Posting das Problem und die Lösung ergibt oder ggfs. einen kompletten Thread oder einen Ausschnitt davon verlinken... ich habe das ja auch nur mal so überlegt. Wenn jetzt z.B. 20 User die nahezu täglich im Forum sind die Möglichkeit dazu haben, dann ist das doch halb so wild! Wieviele wirklich gute Beiträge kommen denn im Schnitt am Tag? So viele sind das auch nicht. Man müßte sich halt Richtlinien überlegen welche Beiträge wie aufgenommen werden. Dann sollte das doch gut funktionieren! Nur denke ich nicht das das funktioniert, wenn das alle machen, denn Quantität ist nicht gleich Qualität ;-) Und das würde bestimmt der Qualität des Forums und überhaupt des SELFraums weiter nach oben verhelfen, oder?

      Grüße
      Andreas

      1. Moin!

        War mir nicht bekannt, dachte das seien alles extra formulierte Artikel. Und von wegen Arbeit, man könnte das ganze ja auch verteilen, s.u.

        Naja, verteilt ist es schon: http://aktuell.de.selfhtml.org/people/devs.htm.

        Sicher, so ist das nunmal mit solchen Funktionen und er Allgemeinheit. Wenn denn mal die neue Version des Forums rauskommt, dann hat man ja vermutlich auch eine Art Rechtesystem, schon im allgemeinen Forum, nicht nur über einen speziellen Zugang. Somit könnte man einigen Usern die sich dazu bereit erklären und bekanntermaßen "viel Ahnung von allem" haben, ein etwas ausführlicheres "In die FAQ aufnehmen" anzeigen, evtl. mit Auswahl der genauen Kategorie + Unterkategorie und ggfs. Vergabe eines aussagekräftigeren Titels.

        Von Rechtesystem hab ich bisher noch nicht viel gesehen. Wird also nichts werden mit deiner Idee.

        Und dann dieses Posting direkt in den FAQ speichern, oder vielleicht von jemanden noch freigeben lassen, evtl. ganz vielleicht noch eine Möglichkeit etwas am Text zu ändern, das sich aus dem einen Posting das Problem und die Lösung ergibt oder ggfs. einen kompletten Thread oder einen Ausschnitt davon verlinken...

        Das Problem der FAQ ist: Niemand liest sie, weil sie schon jetzt so groß ist. Immer wieder kommen häufig gestellte Fragen wie "Zweiframes ändern" ins Forum, weil niemand die FAQ liest.

        Wenn die FAQ jetzt immer größer und größer würde - würde sie noch unübersichtlicher und dennoch nicht häufiger gelesen.

        Wenn jetzt z.B. 20 User die nahezu täglich im Forum sind die Möglichkeit dazu haben, dann ist das doch halb so wild! Wieviele wirklich gute Beiträge kommen denn im Schnitt am Tag? So viele sind das auch nicht. Man müßte sich halt Richtlinien überlegen welche Beiträge wie aufgenommen werden. Dann sollte das doch gut funktionieren!

        Es gibt die Developer, die sich täglich Gedanken machen, welche der gefragten Probleme sich gut für einen Tipp-Artikel eignen würden - auch weil Fragen häufiger kommen. Und sie recherchieren Themen und Autoren, die Artikel schreiben. Manpower ist genug da - es mangelt meist deutlich an der Eigeninitiative oder den persönlichen Möglichkeiten der hier Fragenden, sich vor ihrem Posting selbst zu informieren. Da kann man mit noch soviel Informationsangebot nichts tun.

        - Sven Rautenberg

        1. Hi!

          War mir nicht bekannt, dachte das seien alles extra formulierte Artikel. Und von wegen Arbeit, man könnte das ganze ja auch verteilen, s.u.

          Naja, verteilt ist es schon: http://aktuell.de.selfhtml.org/people/devs.htm.

          Ich meine mehr so nebenbei! Die Leute die da stehen können wenn Sie wollen Beiträge für die FAQ speichern. Nicht als riesen-Aufgabe, ich stelle mir das so vor, man liest den Beitrag, denkt das könnte sollte  aufnehmen, hat dann diekt ein Feld wo man den Titel ändern kann und noch eins oder 2 um die Kategorie und Unterkategorie auszuwählen und fertig.

          Von Rechtesystem hab ich bisher noch nicht viel gesehen. Wird also nichts werden mit deiner Idee.

          Naja, CK hatte mal irgendwann vor ein paar Monaten was durchsickern lassen, von wegen "neues Forum" in C. Wenn man möchte soll man sich da auch registrieren können, um seinen Namen zu schützen und erweiterte Dienste wie Email-Benachrichtigung in Anspruch nehmen zu können. Jedenfalls ist hierfür irgendeine Art von Rechtesystem notwendig, egal wie einfach. Und das könnte man doch verwenden, wenn der eingelogte User "Sven Rautenberg" (was dann natürlich geschützt sein muß) heißt, dann erscheint statt "Artikel zur Archivierung vorschlagen" dafür "Artikel in FAQ speichern" mit den 2-3 besagten Feldern, und einem submit-Button und fertig.

          Und dann dieses Posting direkt in den FAQ speichern, oder vielleicht von jemanden noch freigeben lassen, evtl. ganz vielleicht noch eine Möglichkeit etwas am Text zu ändern, das sich aus dem einen Posting das Problem und die Lösung ergibt oder ggfs. einen kompletten Thread oder einen Ausschnitt davon verlinken...

          Das Problem der FAQ ist: Niemand liest sie,

          ja ich auch nicht! Die FAQ von SELFhtml sind nach meinem persönlichen Empfinden unangenehm zu lesen! Ganz im Gegensatz zu Tipps + Tricks und den Featured Artikeln. So müßten die neuen FAQ aufgebaut sein.

          weil sie schon jetzt so groß ist.

          Ja. Und daher braucht man 2 FAQ, einmal die "redaktionellen" wie das jetzt der Fall ist, evtl. noch vereinfacht und an mehr Stellen und offensichtlicher verlinkt, und dann noch die anderen FAQ, die mehr eine Art nach Themen und nicht nach Zeit unterteilte Oberfläche für das Archiv, bzw. die besten Beiträge daraus. Und das ganze müßte rel. weit verzweigt sein, halt nicht wie die bisherigen FAQ, sondern eine Mischung aus der Featured Artikeln-Navigation und der SELFHTML-Navigation selbst.

          Immer wieder kommen häufig gestellte Fragen wie "Zweiframes ändern" ins Forum, weil niemand die FAQ liest.

          Ja, das ist wohl richtig, daher würde ich wie schon gesagt die "Häufigen Anfänger Fragen" weiter reduzieren, denn die wissen eigentlich gar nicht genau wonach sie suchen wollen und können mit Fachbegriffen noch nicht viel anfangen. Und wenn dann da 100 Fragen stehen hat man nach der 20. keine Lust mehr weiterzulesen und landet dann früher oder später im Forum. Also die _allerhäufigsten_ Fragen belassen und besser verlinken und kennzeichnen. Von da aus kann man ja dann auch auf die erweiterten FAQ verweisen, vielleicht hat man da auch zu jedem Thema einen "Anfängerfagen-Bereich", auf den man dann jeweils verweisen könnte, oder bei Fragen im Forum einen passenden Link posten kann.

          Wenn die FAQ jetzt immer größer und größer würde - würde sie noch unübersichtlicher und dennoch nicht häufiger gelesen.

          Stimmt. Vielleicht ist der Begriff "FAQ" auch falsch gewählt, vielmehr meine ich eine weitere Zugrifsmöglichkeit auf die Beiträge im Archiv, und am besten dann natürlich nur auf die guten Beiträge!

          Es gibt die Developer, die sich täglich Gedanken machen, welche der gefragten Probleme sich gut für einen Tipp-Artikel eignen würden - auch weil Fragen häufiger kommen. Und sie recherchieren Themen und Autoren, die Artikel schreiben. Manpower ist genug da - es mangelt meist deutlich an der Eigeninitiative oder den persönlichen Möglichkeiten der hier Fragenden, sich vor ihrem Posting selbst zu informieren. Da kann man mit noch soviel Informationsangebot nichts tun.

          Vielleicht hast Du Recht, dass es den Anfängern nicht so viel bringt, aber Leuten wie mir wäre dadurch sehr geholfen, die Featured Artikel finde ich eigentlich fast das interessanteste an Selfaktuell! Aber wenn man sich überlegt was für ein Potential im Selfarchiv noch schlummert, wäre es eine einzigartige "Einrichtung", und daber erheblich recourcensparender als die Suche!

          Aber es war nur mal eine Idee die mir so in den Kopf gekommen ist, vielleicht ist es auch gar nicht nötig und es reicht die Suchfunktion,  wollte es auch nur einfach mal zur Diskussion stellen!

          Viele Grüße
          Andreas

    2. Hallo, Orlando,

      http://selfhtml.org/sfausles/

      Krass, ich wusste zwar, dass diese Forumsauslese existiert, hatte sie aber noch nicht zu Gesicht bekommen. Ein hoffnungslos veraltetes Dokument aus der finsteren Zeit des Browserwars... :) Davon würde ich heutzutage fast nichts mehr empfehlen, bis auf ein paar immergrüne Tipps.

      Da könnte man sich doch mal überlegen, so eine Art FAQ zu erstellen, die dann jeweils auf den/die besten Postings oder Threads zu diesem Thema verweist.

      Wunderbar - ich danke dir für dein Engagement! Wenn du das ernsthaft machen willst, kommt sehr viel Arbeit auf dich zu :)

      Sobald es hier persistente Links gibt, werde ich eine ("private") FAQ-Liste starten. Momentan habe ich weder Lust noch Zeit, dutzende Threads Tage nach dem Lesen noch einmal im Archiv zu suchen. Leider habe ich nicht einmal dynamischen Speicherplatz, sodass ein einfaches Administrationsinterface nicht möglich ist, zumindest nicht öffentlich zugänglich.

      Mir würde es aber schon gefallen, wenn man hier einen einfachen FAQ-Generator bauen könnte, in welchen jeder Fragen, Antworten und Postingverweise eintragen kann. Vielleicht werde ich so etwas mal entwickeln, aber ich kann nicht einmal mit XML ausreichend umgehen, deshalb bezweifle ich, dass den den Devs von Nutzen wäre. :)

      Ich persönliche finde die Archivsuche auch verbesserungswürdig (nein, es wäre möglich, sie zu verbessern :)), aber da ich im Gegensatz zu Michael die Interna nicht kenne, erlaube ich mir darüber kein Urteil. Beispielsweise ist das Ranking für mich nicht nachvollziehbar, aber das ist auch sicherlich nicht einfach.

      Dass Metadaten für das Archiv bereitgestellt werden müssen, steht jedoch außer Frage, strittig ist nur, wie man das realisieren kann.

      Grüße,
      Mathias

      1. Hi Mathias,

        Ich persönliche finde die Archivsuche auch
        verbesserungswürdig (nein, es wäre möglich, sie zu
        verbessern :)),

        ich auch. ;-)

        Beispielsweise ist das Ranking für mich nicht
        nachvollziehbar, aber das ist auch sicherlich nicht
        einfach.

        Welches Ranking?

        Die Treffer werden ganz primitiv linear aus der jeweiligen Indexdatei herausgefiltert ... da bewertet niemand irgendwas.
        Das würde ja noch viiiiel länger dauern ... vor allem würde dann das Trefferlimit nicht mehr zuschlagen, wenn jemand nach "HTML" sucht ... weia!

        Viele Grüße
              Michael

        1. Hallo!

          Ich persönliche finde die Archivsuche auch
          verbesserungswürdig (nein, es wäre möglich, sie zu
          verbessern :)),

          ich auch. ;-)

          und ich erst! Ich will endlich eine Datenbank, biiiitttteeeee!!!
          ;-))

          Beispielsweise ist das Ranking für mich nicht
          nachvollziehbar, aber das ist auch sicherlich nicht
          einfach.

          Welches Ranking?

          wie wärs mit dem Datum?

          Die Treffer werden ganz primitiv linear aus der jeweiligen Indexdatei herausgefiltert ... da bewertet niemand irgendwas.
          Das würde ja noch viiiiel länger dauern ... vor allem würde dann das Trefferlimit nicht mehr zuschlagen, wenn jemand nach "HTML" sucht ... weia!

          Mal ganz ehrlich, Du kennst Dich doch wirklich mit MySQL aus wie kaum einer hier, und wenn ich nicht irre war die Suche in PERL geschrieben, oder? Alle paar Sekunden eine 106 MB große Textdatei zu parsen, das ist doch Wahnsinn! Sicher, funktionieren tut das, aber eine DB ist genau darauf optimiert und erledigt das ganze mit C oder C++. Ich merke das schon wenn ich 1 MB parse mit PHP, gut, ich kann das nicht so wie Ihr optimieren, aber wenn ich dieselbe Information aus der DB hole ist das erheblich schneller - wenn die Verbindung bereits besteht. Aber gerade das ist ja das gute, der Aufbau der Verbindung dauert evtl, aber kostet kaum Performance. Außerdem kann eine DB sehr viel besser mit vielen Anfragen gleichzeitig umgehen. Man könnte die Textdateien doch rel. einfach in eine gaaaanz einfache MySQL-Tabelle schreiben, schön mit FULLTEXT Index..., vielleicht sollte man dafür mySQL 4-beta verwenden, denn es ist ja keine wirklich "wilde" Anwendung, und Version 4 soll zum einen nochmal schneller sein, aber vor allem besser für FULLTEXT Suche  einzustellen sein - aber wem sag ich das ;-) Mich wundert das halt nur. Nicht das eines Tages ein Prozessor durschschmort ;-)
          Würde mich sehr interessieren wie der Stand der Dinge ist. Oder meinst Du das wäre auch nicht viel schneller?

          Viele Grüße
          Andreas

          1. Hallo Andreas,

            Mal ganz ehrlich, Du kennst Dich doch wirklich mit MySQL aus wie kaum einer hier, und wenn ich nicht irre war die Suche in PERL geschrieben, oder? Alle paar Sekunden eine 106 MB große Textdatei zu parsen, das ist doch Wahnsinn!

            Stimmt schon - und eine DB-basierte Suche ist ja auch laengst in Entwicklung. Es gibt hier auf dem Server sogar ein CVS-Projektverzeichnis dafuer. Aber es sind halt alles freiwillige Leistungen, und so kann es eben auch mal vorkommen, dass Projekte ueber laengere Zeit stocken. Wenn du Interesse hast, dann melde dich mal bei Daniela Koller und sprich sie auf das Projekt an. Vielleicht kannst du oder sonst jemand sie ja unterstuetzen!?

            viele Gruesse
              Stefan Muenz

          2. Hi Andreas,

            Welches Ranking?
            wie wÃrs mit dem Datum?

            die Indexdateien werden bereits so sortiert, daà die Treffer in umgekehrter Reihenfolge der Entstehung der Postings gefunden werden.
            Diese Art des "Ranking" ist also schon im Indexer vorhanden - die Suchfunktion selbst tut da nichts mehr.

            wenn ich nicht irre war die Suche in PERL
            geschrieben, oder? Alle paar Sekunden eine 106 MB
            groÃe Textdatei zu parsen, das ist doch Wahnsinn!

            Das ist die RealitÃt. ;-)
            Schau Dir die angegebenen CPU-Zeiten an - so schlimm ist das gar nicht.

            Das Forum, welches mit noch hÃherem Aufwand die (allerdings kleineren) Thread-Dateien parsed, wird fÃnfzehnmal so oft aufgerufen wie die Suche - und das kostet auch ganz schÃn viel Last.
            Insofern finde ich es auch richtig, daà Christian dort ansetzt und den Kern in einer grundsÃtzlich anderen Architektur neu schreibt - _das_ wird ein Quantensprung werden, wenn es mal stabil lÃuft.

            Sicher, funktionieren tut das, aber eine DB ist
            genau darauf optimiert und erledigt das ganze mit C
            oder C++.

            Die Sprache fÃr das biÃchen HTML drum herum ist vÃllig egal - nur die Sucherei kostet.
            Meine Suchmaschinen hier im BÃro sind auch alle in Perl geschrieben und nicht in C.

            Ich merke das schon wenn ich 1 MB parse mit PHP,
            gut, ich kann das nicht so wie Ihr optimieren,

            Machst Du denn eine entsprechende Schwachstellenanalyse? (CPU-Zeit-Messung fÃr jeden einzelnen Schritt Deines Programms.)

            FÃr die Archiv-Suche gibt es in deren Dokumentation ein Kapitel, welches fÃr jeden einzelnen Schritt die relative CPU-Last innerhalb des Such-Vorgangs beschreibt - und die 100 MB zu lesen ist noch nicht mal der grÃÃte Anteil, wenn ich das richtig in Erinnerung habe (das Splitten der Felder ist ziemlich teuer, beispielsweise - das ist aber in der Architektur des Datenformats begrÃndet. Dieses zu Ãndern hÃtte bedeutet, auch den Schwanzabschneider umzuschreiben - das war damals nicht erlaubt).

            aber wenn ich dieselbe Information aus der DB hole
            ist das erheblich schneller

            Das Berechnen der Informationen wÃrde unter Verwendung einer baumartigen Datenstruktur sicherlich schneller gehen.
            Aber (wie Dir auch eine Archivsuche hÃtte klar machen kÃnnen): Eine solche Baumstruktur ist prima geeignet fÃr eine Wort-Suche, nicht aber fÃr eine Phrasen-Suche, welche die Self-Suche bisher unterstÃtzt.
            mySQL-FULLTEXT _ist_ toll, erfÃllt aber nicht die Aufgabenstellung, die bisherige Suche nachzubilden.
            Und ich bin nicht befugt, Aufgabenstellungen zu definieren (oder gar abzuÃndern).

            AuÃerdem kann eine DB sehr viel besser mit vielen
            Anfragen gleichzeitig umgehen.

            Wie kommst Du darauf?
            Abgesehen davon, daà praktisch keine gleichzeitigen Abfragen vorkommen - im Mittel wird tagsÃber alle 5 Sekunden eine Suche gestartet, und die dauert deutlich weniger als 5 CPU-Sekunden. Es mag lokale Peaks geben, aber der Normalfall ist das nicht. (Christian hat ja auch einen Ãberlaufschutz bei zu vielen gleichzeitigen Such-Aufrufen eingebaut - wie oft feuert der?)

            Man kÃnnte die Textdateien doch rel. einfach in
            eine gaaaanz einfache MySQL-Tabelle schreiben,
            schÃn mit FULLTEXT Index...,

            Welche MindestlÃnge fÃr einen Suchbegriff soll die Suche erzwingen? Bei mySQL sind das 4 Zeichen - alles KÃrzere wird gar nicht erst gespeichert!

            Was ist mit der eingebauten Stop-Wort-Liste? mySQL entscheidet willkÃrlich, ein paar hundert Worte fÃr insignifikant zu halten und nicht zu speichern. Das kann man mÃgen oder auch nicht ...

            Ich muÃte den mySQL-Quelltext jedenfalls entsprechend anpassen und neu Ãbersetzen, um FULLTEXT fÃr meine Zwecke brauchbar zu machen.

            vielleicht sollte man dafÃr mySQL 4-beta verwenden,

            3.x reicht m. E. vÃllig aus. In 4.0 wird zwar einiges konfigurierbar, was bisher fest verdrahtet ist, und die Suche soll auch schneller und mÃchtiger werden ... fÃr eine reine Wortsuche ist 3.x schon sehr gut geeignet.

            WÃrde mich sehr interessieren wie der Stand der
            Dinge ist. Oder meinst Du das wÃre auch nicht viel
            schneller?

            Das wird bei groÃen Datenmengen _erheblich_ schneller! (NÃmlich logarithmisch statt linear.) Deshalb habe ich mir im BÃro ja auch angetan, den mySQL-Quelltext zu Ãndern ... mein "Archiv" enthÃlt momentan das Ãquivalent von einer Million "Postings", und die Suche ist bei Verwendung 'guter' Suchbegriffe erfreulich schnell.
            Der Super-GAU sind dann natÃrlich Suchbegriffe, welche sehr viele Treffer liefern - da verliert die Indexstruktur vÃllig ihren Nutzeffekt, im schlimmsten Falle kann ihre Verwendung sogar langsamer werden als ein full table scan. Man sollte dann also nicht nach "HTML" suchen ...

            Viele GrÃÃe
                  Michael