Stefan Alfke: gereizte Stimmung im Forum?!

0 124

gereizte Stimmung im Forum?!

Stefan Alfke
  • zu diesem forum
  1. 0
    molily
    • menschelei
    1. 0
      Christian Seiler
      1. 0
        Mathias Bigge
        1. 0
          Dave
        2. 0
          Michael N.
      2. 0
        Phil
        1. 0
          Fabian Transchel
          1. 0
            Phil
            1. 0
              Mathias Bigge
              1. 0
                Chräcker Heller
                1. 0

                  würzlastige Erben Amins

                  Mathias Bigge
    2. 0
      Christoph Schnauß
  2. 0
    Chräcker Heller
    1. 0
      Dave
      1. 0
        Mathias Bigge
      2. 0
        Fabian Transchel
        1. 0
          Dave
          1. 0
            Christian Seiler
            1. 0
              Orlando
              1. 0
                Christian Seiler
  3. 0
    Franz
  4. 0
    Lude
    1. 0
      Christian Kruse
      1. 0
        Lude
        1. 0
          Christian Kruse
          1. 0
            Lude
            1. 0
              Fabian Transchel
              1. 0
                Lude
                1. 0
                  Fabian Transchel
            2. 0
              Christian Kruse
              1. 0
                Lude
                1. 0
                  Dave
                2. 0
                  Mathias Bigge
                  1. 0
                    Christian Kruse
                  2. 0
                    Lude
  5. 0
    Stefan Alfke
    1. 0
      Chräcker Heller
      1. 0
        Sonia
        1. 0
          Chräcker Heller
          1. 0

            Kritik an der FAQ - Kurzfassung erforderlich?

            Mathias Bigge
            1. 0
              Chräcker Heller
              1. 0
                Christian Seiler
                1. 0
                  Chräcker Heller
                2. 0
                  Michael Schröpl
                  1. 0
                    Lude
                    1. 0
                      Michael Schröpl
                      1. 0
                        Lude
                        1. 0

                          FAQ - verfolgung unterschiedlicher Ziele!

                          Sonia
                        2. 0
                          Michael Schröpl
                      2. 0
                        Andreas Korthaus
                        1. 0
                          Michael Schröpl
                          1. 0
                            Andreas Korthaus
                            1. 0
                              Michael Schröpl
                              1. 0
                                Lude
                              2. 0
                                Andreas Korthaus
                                1. 0
                                  Michael Schröpl
                                  1. 0
                                    Andreas Korthaus
                                    1. 0

                                      Archiv-Suchmaschine: Modell-Diskussion

                                      Michael Schröpl
                                      • programmiertechnik
                                      1. 0
                                        Andreas Korthaus
                                        1. 0
                                          Michael Schröpl
                                          1. 0
                                            Andreas Korthaus
                                            1. 0
                                              Christian Kruse
                                              1. 0
                                                Andreas Korthaus
                                                1. 0
                                                  Christian Kruse
                                                  1. 0
                                                    Andreas Korthaus
                                                    1. 0
                                                      Christian Kruse
                                                      1. 0
                                                        Michael Schröpl
                                                        1. 0
                                                          Christian Kruse
                                                          1. 0
                                                            Michael Schröpl
                                                            1. 0
                                                              Christian Kruse
                                                              1. 0
                                                                Michael Schröpl
                                                              2. 0
                                                                Michael Schröpl
                                                                1. 0
                                                                  Christian Kruse
                                                                  1. 0
                                                                    Michael Schröpl
                                                                    1. 0
                                                                      Christian Kruse
                                                                      1. 0
                                                                        Michael Schröpl
                                                                        1. 0
                                                                          Christian Kruse
                                                                          1. 0
                                                                            Michael Schröpl
                                                    2. 0
                                                      Michael Schröpl
                                                2. 0
                                                  Michael Schröpl
                                                  1. 0
                                                    Daniela Koller
                                                    1. 0
                                                      Christian Kruse
                                                      1. 0
                                                        Daniela Koller
                                                        1. 0
                                                          Christian Kruse
                                                          1. 0
                                                            Daniela Koller
                                                            1. 0
                                                              Christian Kruse
                                                              1. 0
                                                                Daniela Koller
                                                                1. 0
                                                                  Christian Kruse
                                                                2. 0
                                                                  Michael Schröpl
                                                                  1. 0
                                                                    Andreas Korthaus
                                                                    1. 0
                                                                      Christian Kruse
                                                                  2. 0
                                                                    Daniela Koller
                                                              2. 0
                                                                Michael Schröpl
                                                                1. 0
                                                                  Christian Kruse
                                              2. 0
                                                Michael Schröpl
                                                1. 0
                                                  Christian Kruse
                                                  1. 0
                                                    Michael Schröpl
                                                    1. 0
                                                      Christian Kruse
                                                      1. 0
                                                        Michael Schröpl
                                                        1. 0
                                                          Christian Kruse
                                                          1. 0
                                                            Michael Schröpl
                                                            1. 0
                                                              Christian Kruse
                                                              1. 0
                                                                Christian Kruse
                                                                1. 0
                                                                  Michael Schröpl
                                                                  1. 0
                                                                    Christian Kruse
                                                                    1. 0
                                                                      Michael Schröpl
                                                                      1. 0
                                                                        Christian Kruse
                              3. 0
                                Mathias Bigge
                    2. 0
                      Mathias Bigge
                      1. 0
                        Lude
              2. 0
                molily
                1. 0
                  Chräcker Heller
                  1. 0
                    Sonia
  6. 0
    Kai Lahmann
    1. 0
      Chräcker Heller
      1. 0
        Kai Lahmann
    2. 0
      Daniel
      1. 0
        Kai Lahmann
        1. 0
          Daniel
          1. 0
            Kai Lahmann
            1. 0
              Daniel
              1. 0
                Kai Lahmann
  7. 0
    Chef

Hallo,

mir ist aufgefallen, das einige Forum-User in letzter Zeiter sehr gereitzt auf Postings von Neulingen reagieren. Sicherlich kommt es vor, das einige Fragen zu x-ten mal gestellt werden.

Ist das denn ein Grund gleich so aus der Haut zu fahren?

Ich finde tollerranz tut uns allen gut, wir alle sind mal mit html, java-script, php und perl angefangen. Wenn zum Beispiel die Lösung zu einer Frage in selfhtlm schon vorhanden ist, wäre bei der ein link auf die quelle meinener Meinung nach sinnvoller als immer auf die Forumsregeln zu verweisen.

Gebt doch newbies eine Chance, anstatt sie zu vertreiben. Wir ärgern uns sonst nur über schlechte Programmiertechniken im Netz.

Mich würde Eure Meinung hierzu interessieren.

Gruss

Stefan Alfke

  1. Hallo, Stefan,

    Ich finde tollerranz tut uns allen gut

    <img src="http://www.your-boredom.de/stuff/mehr_trolleranz.gif" border="0" alt="">

    Grüße,
    Mathias
    P.S. Entschuldige - mir fällt momentan nichts anderes ein, denn diese ständigen Metadiskussionen nehmen für meinen Geschmack überhand, zudem wird das von dir angesprochene Thema alle paar Tage durchgekaut, weshalb man meiner Meinung nach dazu nichts gehaltvolleres mehr sagen kann.

    --
    Remember: KING KONG Died For Your Sins!
    "Wie ein gefoppter Nachtmahr der auf Tücke sinnt..." (Hugo Ball, "Die Katze")
    1. Hallo Stefan, Hallo Mathias,

      Ich finde tollerranz tut uns allen gut

      s/tolleranz/Toleranz/

      P.S. Entschuldige - mir fällt momentan nichts anderes ein, denn diese ständigen Metadiskussionen nehmen für meinen Geschmack überhand, zudem wird das von dir angesprochene Thema alle paar Tage durchgekaut, weshalb man meiner Meinung nach dazu nichts gehaltvolleres mehr sagen kann.

      Full ACK. Ständig beschweren sich Leute, dass hier im Forum auch etwas von ihnen verlangt wird, wenn sie ein Problem haben. Und in letzter Zeit wird das wirklich immer mehr.

      Und ich finde auch die Pauschalaussage "Hier werden Newbies niedergemacht" einfach falsch. Wenn jemand die entsprechenden Bereiche von SELFHTML gelesen und versucht zu verstehen hat, dann wird ihm auch geholfen, egal wie "blöd" seine Frage ist.

      Grüße,

      Christian

      --
      Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
                            -- Albert Einstein
      1. Hi Christian,

        alles richtig, aber natürlich bedarf einiges, was uns selbstverständlich geworden ist, der Erklärung für die Leute, die neu zu uns stoßen.

        Und ich finde auch die Pauschalaussage "Hier werden Newbies niedergemacht" einfach falsch. Wenn jemand die entsprechenden Bereiche von SELFHTML gelesen und versucht zu verstehen hat, dann wird ihm auch geholfen, egal wie "blöd" seine Frage ist.

        Ganz interessant, vielleicht bleibt es aber eine Illusion, dass jemand, der zufällig in ein Forum gerät, erstmal gründlich die FAQ liest, dass er sich sein Posting überlegt, bevor er auf Abschicken drückt, dass er sich bewusst macht, dass er es mit lebendigen Menschen zu tun hat, die freundschaftlich zusammenarbeiten und nicht mit einer Antwortmaschinerie, dass im Internet manchmal ein rauher, aber herzlicher Ton herrscht, dass man in technischen Foren ein Minimum an Eigenleistung erwartet usw. ppp. ...

        Meist hat jemand ein Problem, meint, ohne die sofortige Lösung nicht weiterleben zu können *g*, hat noch nicht die Erfahrung gemacht, dass solche Hänger beim Proggen ganz normal sind und dass nur Gelassenheit und langsamer Aufbau von Lösungskompetenz hilft. Dann stößt er irgendwie auf diese Community, und wie ein Ertrinkender im eisigen Wasser, bölkt er erstmal: "HIILLLFFEEE!"

        Oder da ist ein Jugendlicher, hat in vielen Stunden seine erste Site gebastelt, und bittet jetzt stolz wie Oskar um "Bewertung", erwartet aber in Wirklichkeit natürlich väterliches Lob, und quiekt natürlich wie ein Schwein beim Metzger, wenn jemand, anders als die liebe Mutti, was Kritisches anmerkt.

        Was das für die Stammposter heißt?

        1. Nicht vergessen, dass wir selbst mal blöd angefangen haben.
        2. Dass Offenheit der Community eine Überlebensfrage ist.
        3. Zu gucken, ob der eine oder andere, der hier ungehobelt hereinpoltert, nicht doch ein Potential für uns mitbringt.
        4. Dass Abgrenzungsmechanismen ein automatischer und schädlicher Reflex jeder Gemeinschaft zur Identitätsbildung ist.
        5. Mal auf die emotionale Bremse drücken, vielleicht, indem man sich an die eigenen Anfänge erinnert, vielleicht, indem man sich den Jugendlichen vorstellt, der da mit einigem Schiss zum ersten Mal postet und seine frisch erworbenen "Erkenntnisse" einer wissenden Öffentlichkeit präsentiert...

        Und für die Newbies:

        1. SCHREI NICHT! Auch wenn Du meinst, Dein Problem sei das einzig wichtige auf dieser Welt, niemand wird Dir helfen, wenn Du nicht höflich und sachlich schilderst, was Du versuchst und worum es geht.
        2. RESPEKT! Die Leute, die Dir hier helfen sollen, bringen eine geballte Ladung an Erfahrung mit, und sie tun dies ehrenamtlich und unbezahlt. Warum sollten sie sich von Dir von der Seite anquatschen lassen?
        3. GEDULD! Viele der Poster hier arbeiten seit Jahren zusammen, halten Kontakt über Chat, Treffen, entwickeln das Projekt, das Du nutzt, gemeinsam weiter. Man will etwas von Dir sehen, zumindest ENgagement und guten Willen über einige Zeit, wenn Du dazugehören willst, auch eine gewisse Frustrationstoleranz. Wir sind alle mal von den Urgesteinen abgehalftert worden, meist zu Recht, wie man im Nachhinein zugeben muss.
        4. ARBEIT! Für fast alles, was an Problemen hier gepostet wird, gibt's eine durchdachte und fertige Löung im Selfraum: In der FAQ, in den Feature-Artikeln, in Tipps & Tricks, in der Linkliste, im Archiv und natürlich nicht zuletzt in SelfHTML. Alle diese Bereiche sind über die Suche zugänglich. Also, lies Dich mal ein, verschaff Dir eine Wissensbasis, das wird die Qualität Deiner Fragestellung verbessern und das weiß man hier zu schätzen.
        5. DRANBLEIBEN! Wir freuen uns über neue Leute, auch wenn's manchmal etwas ruppig zugeht hier. Also: Nicht gleich den Kopf in den Sand stecken, wenn's mal nen Rüffel gibt. <duck>Der Sven, der Roland, der Christoph, der Cheatah und der Christian sind gar nicht so *g*</duck>

        Viele Grüße
        Mathias Bigge

        --
        http://www.selfaktuell.teamone.de/tippstricks/index.htm
        Habe am Wochenende im Lotto verloren -> bin untröstlich.
        1. Hi,

          SCHREI NICHT!

          Welch Ironie... *g*

          Schoene Gruesse,
          Dave

        2. Hi Matthias,

          1. ARBEIT! Für fast alles, was an Problemen hier gepostet wird, gibt's eine durchdachte und fertige Löung im Selfraum: In der FAQ, in den Feature-Artikeln, in Tipps & Tricks, in der Linkliste, im Archiv und natürlich nicht zuletzt in SelfHTML. Alle diese Bereiche sind über die Suche zugänglich. Also, lies Dich mal ein, verschaff Dir eine Wissensbasis, das wird die Qualität Deiner Fragestellung verbessern und das weiß man hier zu schätzen.

          Zuerst entsteht zwar bei dem Fragesteller Frust, weil er gerade nicht die Fertig-Lösung bekommt, meist, finde ich, ist es aber am Ende so, daß der Fragesteller mit seiner Lösung, die er anhand von Tips, Fragen und Links selber erarbeitet hat, wesentlich zufriedener ist.

          Bis denndann

          Michael N.

      2. Wenn jemand die entsprechenden Bereiche von SELFHTML gelesen und versucht zu verstehen hat, dann wird ihm auch geholfen, egal wie "blöd" seine Frage ist.

        Jenau, WENN!
        Aber wenn nicht, wird er harsch angemacht. Oder es wird aufs Archiv verwiesen. Oder eben auf die Forumsregeln.

        Ich kann nur von Glück reden, dass ich SelfHTML früher entdeckte, als das Forum hier. Stellt euch die Leute vor, die zufällig per Suchmaschine oder Link hier landen, vollkommene Newbies, SelfHTML sagt denen nichts (ja, sowas gibt es sogar mehr, als ich dachte) und die posten hier ihre Probleme. Daraufhin werden sie harsch angemacht, dass die doch vorher "SelfHTML" oder "das Archiv" lesen sollen. Woher sollen die wissen, was das ist. Ihr könnt mir auch nicht andrehen, dass ihr, wenn ihr mal ein Problem habt und neu im Forum seid, erstmal die gesamte Seite durchstöbert, ehe ihr postet. Wobei ihr wieder den Vorteil habt, IHR wisst, was ein Archiv, eine Forumssuche und SelfHTML ist. Die Newbies nicht.

        Naja, es ist eh unsinnig, mit einer Wand zu reden, erlebe ich hier nicht das erste Mal..
        Von daher: Ist nur meine bescheidene, nichtssagende, auf dem Niveau eines billigen Users basierende Meinung...
        CU
        http://www.yubb.de

        1. Hi Phil...

          Wenn jemand die entsprechenden Bereiche von SELFHTML gelesen und versucht zu verstehen hat, dann wird ihm auch geholfen, egal wie "blöd" seine Frage ist.
          Jenau, WENN!
          Aber wenn nicht, wird er harsch angemacht. Oder es wird aufs Archiv verwiesen. Oder eben auf die Forumsregeln.

          Und das ist gut so. Wenn es in einem nicht allzu nasebügelnden[tm] Tonfall gescheit. Vor allem ist es, und das weißt du, legitim.

          Ich kann nur von Glück reden, dass ich SelfHTML früher entdeckte, als das Forum hier. Stellt euch die Leute vor, die zufällig per Suchmaschine oder Link hier landen, vollkommene Newbies, SelfHTML sagt denen nichts (ja, sowas gibt es sogar mehr, als ich dachte) und die posten hier ihre Probleme. Daraufhin werden sie harsch angemacht, dass die doch vorher "SelfHTML" oder "das Archiv" lesen sollen. Woher sollen die wissen, was das ist.

          Das steht gaaanz oben auf der Hauptseite. Wenn du eine Seite öffnest, liest du von _Unten nach Oben_? Der Punkt ist halt IMHO, dass garnicht gelesen wird, sondern man blind drauflospostet und schaut, was passiert. Es ist bekannt, was passiert, und das ist, ich wiederhole mich, _gut so_[tm]. Wer nicht einmal diese Seite lesen will, der hat sich vermutlich[tm] nicht einmal mit _seinem_ Problem beschäftigt.

          Ihr könnt mir auch nicht andrehen, dass ihr, wenn ihr mal ein Problem habt und neu im Forum seid, erstmal die gesamte Seite durchstöbert, ehe ihr postet. Wobei ihr wieder den Vorteil habt, IHR wisst, was ein Archiv, eine Forumssuche und SelfHTML ist. Die Newbies nicht.

          Full ACK. Das kann man im Nachhinein alles so sagen, nun, da wir bekehrt[tm] sind. Aber was spricht dagegen, einem Newbie (ich hasse dieses Wort, da es nicht von großem Respekt vor Unwissenden zeugt. N00b passt IMO besser ;-)) zu erklären, wie er vorgehen sollte, um _effizienter_ Arbeiten zu können?

          Naja, es ist eh unsinnig, mit einer Wand zu reden, erlebe ich hier nicht das erste Mal..
          Von daher: Ist nur meine bescheidene, nichtssagende, auf dem Niveau eines billigen Users basierende Meinung...

          Och bitte... darüber bist du nun doch hinaus;-)

          Fabian

          1. Und das ist gut so. Wenn es in einem nicht allzu nasebügelnden[tm] Tonfall gescheit. Vor allem ist es, und das weißt du, legitim.

            Dieser Tonfall ist aber manchmal hier Standard und wenn man sich für diese User einsetzt, dann bekomtm man ein "Don't feed the trolls" vorgesetzt ;)

            Das steht gaaanz oben auf der Hauptseite.

            Jo, das stimmt, aber in IMO gehen diese Links im Gewusel (naja, chaotisch isses hier nicht, aber trotzdem) unter. Und ihr wisst doch alle genau wie ich: Der Mensch springt auf Grafiken an :P aBer da snur am Rande, das Hauptproblem liegt IMO darin, dass eben die Lnks untergehen und gar nicht so als Hyper-duper-mega-giga-wichtig erachtet wie sie es eigentlich sind... :-/

            Aber was spricht dagegen, einem Newbie (ich hasse dieses Wort, da es nicht von großem Respekt vor Unwissenden zeugt. N00b passt IMO besser ;-)) zu erklären, wie er vorgehen sollte, um _effizienter_ Arbeiten zu können?

            zu erklären, aber nicht zu ermahnen, zumal er nichts davon weiß...

            Och bitte... darüber bist du nun doch hinaus;-)

            Ich meinte eher die Relation zu den Übermächtigen Admins und denen, die das Forum tragen, und denen, die nur ab und zu vorbei schauen oder ganz neu hier sind...

            CU
            http://www.yubb.de

            1. Hi,

              Ich meinte eher die Relation zu den Übermächtigen Admins

              Wer ist denn das nun wieder?

              Viele Grüße
              Mathias Bigge

              --
              http://www.selfaktuell.teamone.de/tippstricks/index.htm
              Beitrag verfassen - Proaccount winkt *g*
              1. Hallo,

                Ich meinte eher die Relation zu den Übermächtigen Admins
                Wer ist denn das nun wieder?

                da ist es wieder. Phil schreibt einen wahren Satz(teil), und Du bügelst die Nase. Gut, er hat sich vertippt, aber gerade ich kann das ja nachvollziehen. Er wollte natürlich "Übernächtigten Admins" schreiben, aber das kann man sich doch denken, oder?

                Chräcker

                PS. @Phil: mit viel ;-) natürlich!

                1. Hi Chräcker,

                  das habe ich einfach sehr oberflächlich und mit übermächtigem Blick gelesen, wirklich ich hatte zu wenig Admi in der letzten Zeit...

                  Ich meinte eher die Relation zu den Übermächtigen Admins
                  Wer ist denn das nun wieder?
                  da ist es wieder. Phil schreibt einen wahren Satz(teil), und Du bügelst die Nase. Gut, er hat sich vertippt, aber gerade ich kann das ja nachvollziehen. Er wollte natürlich "Übernächtigten Admins" schreiben, aber das kann man sich doch denken, oder?

                  Ich hatte auch gespürt, dass das ganze in die metaphorische Ecke gehört, konnte aber mit "überfälligem Advent" und "vorgezogenen Kaminsims" nichts anfangen und habe aufgrund meiner nasetrübenden Verzehrgewohnheiten nicht weitergebrüllt. Danke für den Eiopener! Oder meinte er doch "westfälisches Gesims"!?

                  Viele Grüße
                  Mathias Bigge

                  --
                  http://www.selfaktuell.teamone.de/tippstricks/index.htm
                  Beitrag verfassen - übermächtigt werden
                  Gruß an alle Stammposter ;-)
    2. hi Matthias ;-)

      Ich finde tollerranz tut uns allen gut

      ja, finde ich eigentlich auch  -  weil "Tolleranz" ja nach dem 11.11. zum gewohnten Sozialumfeld gehören sollte  -  bis Aschermittwoch. *g*

      ok, ich hab schon mitgekriegt, daß er eigentlich "Toleranz" (mit einem l) gemeint hat, aber ich hab die Lektüre des ganzen etwas anstrengenden Threads auch nur bis hierher durchgestanden, weil ich die "Tolleranz" halt bei Bedarf wörtlich/buchstäblich verstanden habe...

      Grüße aus Berlin

      Christoph S.

  2. Hallo,

    zuerst einmal, und wirklich ernst gemeint und nicht als Beruhigungspille vorneweg: auch ich denke manchmal, daß der Ton nicht immer wirklich newbie-freundlich ist, auch meiner nicht. Ich denke, daß die meisten, die jetzt (wie ich gleich auch ,-)) abwiegeln, schon wissen, daß man manchmal zu spät auf der eigenen Bremse steht ;-)

    Warum also wiegeln die meisten angesprochenen (und vor allem die, die sich angesprochen fühlen) so schnell ab? Es ist nicht unbedingt die Frage nach den 2-Frames (etc) die einen newbie zu einem für uns manchmal schwer erträglichen Newbie macht. Es ist die Art und der Umgang mit dem man den  Postern und "Stammpostern" (die diese Gemeinschaft ja dann doch prägen) begegnet.

    Eine Unerfahrenheit mit technischen Dingen (die man ja wirklich niemanden ankreiden kann) geht nicht selten einher mit einer gewissen Unerfahrenheit im gewünschten Umgangston in diesem Forum. Damit meine ich noch nicht mal das Auslassen von An und Abrede, das ist es noch nicht mal. Es ist eingfach häufig eine Grundhaltung herauszulesen (und vielleicht überintepretieren wir da auch manchmal), die "uns" eben in der art schnell auf die Palme bringt. Fordernd, in keinster Weise sich selbst bemühend (und zwar noch nicht mal in der Problemdarstellung) bis hin zur überzogenen Erwartungshaltung. Wie oft werden hier Poster angemacht, weil sie es wagten Antworten zu geben, die nicht gewollt wurden. (Gewollt wurde eine möglichst fertige Lösung, angeboten(!) wurde eine Auseinandersetzung mit dem (vermeindlich) eigentlichen Problem.

    Viele Newbies wollen sich eben nicht auseinandersetzen. Auseinandersetzung ist hier ausdrücklich gewollt, der Wille dazu ist sogar Pflicht. Das muß ja nicht zwangsläufig gleichgesetzt werden mit "Konflikt", sondern "Auseinandersetzung mit dem Thema" und "Auseinandersetzung mit dem Frageauslösenden Grundproblem" und "Auseiandersetzung mit der Antwort"....

    Es ist in der Tat so, daß sich dieses Forum durch diese "Verpflichtung" zur Auseinandersetzen von fast allen anderen im Netz unterscheidet, aber dann muß sich ein Newbie eben auch den Hinweis gefallen lassen, daß er vielleicht das falsche Forum gewählt hat. Das ist dann, zumindest von meiner Seite, kein Rauswurf (wer bin ich denn!) sondern eher ein hilfegebender Tip: sich dann ein passenderes Forum zu suchen.

    Pauschal(!!!) gebe ich dir aber Recht. Am Umgangston kann ruhig jeder immer wieder mal feilen. Und manchmal hat man auch bei "uns" Stammposter schon das Gefühl, daß da auch mal geschludert wird.

    Chräcker

    1. Hi,

      ...bei "uns" Stammposter schon das Gefühl, daß da auch mal geschludert wird.

      Da faellt mir konkret auch doch glatt diese (gar nicht alte) Geschichte ein, von jemandem (Toby Thaler), der auch ein Stammposter werden wollte, und das ganz doll "cool, cool, cool"[tm], siehe archiv (find den eintrag gerade nicht) fand. Da muss ich Stefan recht geben, den habt ihr so richtig niedergestamft, ihr "Stammposter"...

      Schoene Gruesse,
      Dave

      1. Hi Dave,

        ja,ja, Du kannst es aber drehen und wenden, wie Du willst, inzwischen bist Du auch ein Stammposter geworden. Ich weiß noch, dass Du am Anfang auch ganz schön angemacht worden bist, aber Dich durchgebissen hast. Hat sich doch gelohnt, oder?

        Viele Grüße
        Mathias Bigge

      2. Hi

        ...bei "uns" Stammposter schon das Gefühl, daß da auch mal geschludert wird.

        Da faellt mir konkret auch doch glatt diese (gar nicht alte) Geschichte ein, von jemandem (Toby Thaler), der auch ein Stammposter werden wollte, und das ganz doll "cool, cool, cool"[tm], siehe archiv (find den eintrag gerade nicht) fand. Da muss ich Stefan recht geben, den habt ihr so richtig niedergestamft, ihr "Stammposter"...

        Erstens möchte ich mich Mathias anschließen - du _bist_ schon Stammposter, obwohl du am Anfang auf die Mütze bekamst. Geschadet hat es offensichtlich ja nicht ;-)
        Was die Geschichte mit dem Toby Thaler angeht, ich bin der Meinung, dass man nicht "einfach so" Stammposter[tm] wird. Man entwickelt halt den Drang, hier zu verweilen, und schwupps ist man Stammposter[tm]. Mir ging das auch so, _planen_ kann man das nicht. In diesem Sinne: Willkommen =)

        Fabian

        1. Hi,

          Erstens möchte ich mich Mathias anschließen - du _bist_ schon Stammposter.

          Das finde ich ja jetzt cool, cool, cool! *SCNR*
          Also ich dachte, das dauert laenger... find ich ja richtig nett von euch!

          Schoene Gruesse,
          Dave

          1. Hallo Dave,

            Erstens möchte ich mich Mathias anschließen - du _bist_ schon Stammposter.

            Also ich dachte, das dauert laenger... find ich ja richtig nett von euch!

            Man ist ab dem Zeitpunkt, wo man 15 Threads hier lebend überstanden hat, Stammposter. ;-)

            Grüße,

            Christian

            --
            Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
                                  -- Albert Einstein
            1. Hi Christian,

              Man ist ab dem Zeitpunkt, wo man 15 Threads hier lebend überstanden hat, Stammposter. ;-)

              Mist - ich hoffe, du meinst damit nicht *gestartete* Threads ;)

              LG Roland

              1. Hallo Roland,

                Mist - ich hoffe, du meinst damit nicht *gestartete* Threads ;)

                Nein, natürlich nicht. Sonst haben ein paar Forum-Nerver, die definitiv keine Stammposter sind, schon mehr Threads als wir beide zusammen gestartet... ;-)

                Grüße,

                Christian

                P.S.:

                Die beste Methode, den M$IE zu beschleunigen sind 9,81 m/s²

                *rotfl*

                --
                Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
                                      -- Albert Einstein
  3. Hallo,

    mir ist aufgefallen, das einige Forum-User in letzter Zeiter sehr gereitzt auf Postings von Neulingen reagieren. Sicherlich kommt es vor, das einige Fragen zu x-ten mal gestellt werden.
    Ist das denn ein Grund gleich so aus der Haut zu fahren?

    Wenn man sich so manches "Newbie"-Verhalten anguckt: ja.

    Siehe z.B. [pref:t=30413&m=164264], dsf

    Ciao, Franz

  4. Hi,

    mir ist aufgefallen, das einige Forum-User in letzter Zeiter sehr gereitzt auf Postings von Neulingen reagieren. Sicherlich kommt es vor, das einige Fragen zu x-ten mal gestellt werden.

    richtig, aber war das früher anders ?

    Ist das denn ein Grund gleich so aus der Haut zu fahren?

    In Deutschland ja. Bedenke mal, wer hier postet:
    Akademiker
    angehende Akademiker
    Leute, die es gerne wären (ego u.a.)
    Praktiker mit Killerinstinkt   :-)
    Spezialisten, die gewohnt sind zu reduzieren

    Ich finde tollerranz tut uns allen gut, wir alle sind mal mit html, java-script, php und perl angefangen. Wenn zum Beispiel die Lösung zu einer Frage in selfhtlm schon vorhanden ist, wäre bei der ein link auf die quelle meinener Meinung nach sinnvoller als immer auf die Forumsregeln zu verweisen.

    richtig. tolleranz ist immer gut.

    Gebt doch newbies eine Chance, anstatt sie zu vertreiben. Wir ärgern uns sonst nur über schlechte Programmiertechniken im Netz.

    Na ja, warum eigentlich nicht? - ABer Deinen zweiten Satz habe ich nicht verstanden; bitte ggf. präzisieren.

    Gruss,
    Luddie

    1. Hallo Lude,

      Ist das denn ein Grund gleich so aus der Haut zu fahren?

      In Deutschland ja. Bedenke mal, wer hier postet:
      Akademiker
      angehende Akademiker
      Leute, die es gerne wären (ego u.a.)
      Praktiker mit Killerinstinkt   :-)
      Spezialisten, die gewohnt sind zu reduzieren

      Wie schoen, dass du weisst, wer hier alles postet. Kannst du
      das auch belegen?

      Gruesse,
       CK

      1. Hi,

        keine rein formalen Einwände gegen meine Argumentation!   :-)
        Ich weiss mit wem ich hier kommuniziere. Hab' da gerne mal nachgefragt.

        Gruss,
        Lude

        1. Hallo Lude,

          keine rein formalen Einwände gegen meine Argumentation!   :-)

          Sind sie nicht.

          Ich weiss mit wem ich hier kommuniziere. Hab' da gerne mal
          nachgefragt.

          Ganz offensichtlich nicht genau genug.

          Gruesse,
           CK

          1. Hi Christian,

            keine rein formalen Einwände gegen meine Argumentation!   :-)

            Sind sie nicht.

            Du hast ein sog. Totschlag-Argument genutzt. Wer kann schon <wissenschaftlich-belegbar> (was immer da auch sein mag) nachweisen mit welcher sozialen Gruppe er kommuniziert.

            Ich weiss mit wem ich hier kommuniziere. Hab' da gerne mal
            nachgefragt.

            Ganz offensichtlich nicht genau genug.

            "Ganz offensichtlich" ist natürlich reine Rhetorik.

            Gruss,
            Lude

            1. Hi

              keine rein formalen Einwände gegen meine Argumentation!   :-)

              Sind sie nicht.

              Du hast ein sog. Totschlag-Argument genutzt. Wer kann schon <wissenschaftlich-belegbar> (was immer da auch sein mag) nachweisen mit welcher sozialen Gruppe er kommuniziert.

              Aber er hat Recht. Wenn du es so genau weißt, dann sage mir bitte, welcher sozialen Gruppe ich angehöre, welcher ich gerne angehören würde und definiere meinen aktuellen Bildungstatus (am besten anhand von Abschlüssen - du darfst auch schätzen).

              Ich weiss mit wem ich hier kommuniziere. Hab' da gerne mal
              nachgefragt.

              Ganz offensichtlich nicht genau genug.

              "Ganz offensichtlich" ist natürlich reine Rhetorik.

              Richtig, aber woher weißt du das? Du verwendest diese Rethorik auch und das legt den Schluss nahe, dass deine Arguementation nicht weniger Schwachstellen offenlässt.

              Fabian

              1. keine rein formalen Einwände gegen meine Argumentation!   :-)

                Sind sie nicht.

                Du hast ein sog. Totschlag-Argument genutzt. Wer kann schon <wissenschaftlich-belegbar> (was immer da auch sein mag) nachweisen mit welcher sozialen Gruppe er kommuniziert.
                Aber er hat Recht. Wenn du es so genau weißt, dann sage mir bitte, welcher sozialen Gruppe ich angehöre, welcher ich gerne angehören würde und definiere meinen aktuellen Bildungstatus (am besten anhand von Abschlüssen - du darfst auch schätzen).

                Hi,

                niemand, der ein Totschlag-Argument benutzt hat recht. Dein Bildungsstand ist im Kontext (leider wirklich ) überhaupt nicht von Interesse.
                Dennoch würde ich mal auf was Pädagogisches tippen.   :-)

                Ich weiss mit wem ich hier kommuniziere. Hab' da gerne mal
                nachgefragt.

                Ganz offensichtlich nicht genau genug.

                "Ganz offensichtlich" ist natürlich reine Rhetorik.
                Richtig, aber woher weißt du das? Du verwendest diese Rethorik auch und das legt den Schluss nahe, dass deine Arguementation nicht weniger Schwachstellen offenlässt.

                Ich sülze gelegentlcih mit den Altvorderen mit. Dadurch gibt es kein Mehr an Content, aber ich entlarve. - Und das ist auch gut so.

                Gruss,
                Luddie

                1. Hi

                  Aber er hat Recht. Wenn du es so genau weißt, dann sage mir bitte, welcher sozialen Gruppe ich angehöre, welcher ich gerne angehören würde und definiere meinen aktuellen Bildungstatus (am besten anhand von Abschlüssen - du darfst auch schätzen).

                  niemand, der ein Totschlag-Argument benutzt hat recht. Dein Bildungsstand ist im Kontext (leider wirklich ) überhaupt nicht von Interesse.
                  Dennoch würde ich mal auf was Pädagogisches tippen.   :-)

                  Ganz gut geraten, ich bin Schüler der elften Klasse ;P

                  "Ganz offensichtlich" ist natürlich reine Rhetorik.
                  Richtig, aber woher weißt du das? Du verwendest diese Rethorik auch und das legt den Schluss nahe, dass deine Arguementation nicht weniger Schwachstellen offenlässt.

                  Ich sülze gelegentlcih mit den Altvorderen mit. Dadurch gibt es kein Mehr an Content, aber ich entlarve. - Und das ist auch gut so.

                  Full ACK, die Suche nach Wahrhaftigkeit ist oftmal gewinnbringender, als die nach Wahrheit.

                  Fabian

            2. Hallo Lude,

              Du hast ein sog. Totschlag-Argument genutzt.

              Nein.

              Wer kann schon <wissenschaftlich-belegbar> (was immer da
              auch sein mag) nachweisen mit welcher sozialen Gruppe er
              kommuniziert.

              Das ist es eben: du *kannst* es nicht nachweisen. Du hast
              keinerlei Ahnung, welcher Gruppe ich angehoere, genau so
              wenig hast du Ahnung, zu welcher Gruppe ich gehoeren moechte.
              Also lass deine idiotischen Verallgemeinerungen und
              Vorurteile stecken.

              "Ganz offensichtlich" ist natürlich reine Rhetorik.

              Nein. Das waere es, wenn es keine oeffentlichen
              Gegenbeispiele zu deinen Thesen gaebe. Die gibt es. Du musst
              nur die Augen aufmachen.

              EOT, EOD.

              Gruesse,
               CK

              1. Yo!

                Du hast ein sog. Totschlag-Argument genutzt.

                Nein.

                Wer kann schon <wissenschaftlich-belegbar> (was immer da
                auch sein mag) nachweisen mit welcher sozialen Gruppe er
                kommuniziert.

                Das ist es eben: du *kannst* es nicht nachweisen. Du hast
                keinerlei Ahnung, welcher Gruppe ich angehoere, genau so
                wenig hast du Ahnung, zu welcher Gruppe ich gehoeren moechte.
                Also lass deine idiotischen Verallgemeinerungen und
                Vorurteile stecken.

                Du bist m.E. ein spezialisierter Eierkopf. Deien Argumentation ist humorlos, zu orthogonal und letztlich nur emotional nachvollziehbar. Und nutze nie das altgriechische Wort Idiota, bitte.

                Dein Bildungststand interessiert (m Kontext leider) nicht. Meine Argumemntation bleibt unwiderlegt (weil letztendlich, wie ich einräumen muss, auch nicht falsifizierbar).  :-)

                "Ganz offensichtlich" ist natürlich reine Rhetorik.

                Nein. Das waere es, wenn es keine oeffentlichen
                Gegenbeispiele zu deinen Thesen gaebe. Die gibt es. Du musst
                nur die Augen aufmachen.

                Wo sind die denn? Ein Verweis auf iregndeinen Inhalt darf gepostet werden.

                Gruss,
                Luddie

                PS: Warum eigentlich so uncoole Statements? Hast Du doch nicht nötig.

                1. Hi,

                  [...]

                  So, ich glaube, damit hat sich die Frage "Gereizte Stimmung im Forum?" geklaert...

                  Schoene Gruesse,
                  Dave

                2. Hi Lude,

                  alter Sozailzugehörigkeitsspekulant ;-) Ich hoffe, man kann von Deinem Nick nicht auf entsprechende Gruppenzugehörigkeiten schließen?

                  Du bist m.E. ein spezialisierter Eierkopf.

                  Ein Kopf ist er, einer der Spezialisten ist er auch, mit den Eiern weiß ich nicht, da kenn ich mich nicht aus, aber ich nehm das Ganze Konstrukt mal als äußerst raffiniertes Kompliment ;-)

                  Deien Argumentation ist humorlos, zu orthogonal und letztlich nur emotional nachvollziehbar.

                  Orthogonale Argumente nur emotional nachvollziehbar - Du meinst vielleicht orthopädisch? Oder hast Du rechteckige Emotionen?

                  Meine Argumemntation bleibt unwiderlegt (weil letztendlich, wie ich einräumen muss, auch nicht falsifizierbar).  :-)

                  Herrlich, nicht falsifizierbare Argumentationen, wenn das der gute Popper lesen müsste, aber vielleicht fehlen Deinen Argumentationen einfach nur ganz entscheidend - die Argumente?

                  PS: Warum eigentlich so uncoole Statements?

                  Sicher ist Christian als älterer Akademiker und überlebender Altgrieche überempfindlich, was die öffentliche Demaskierung dieser unabweisbaren, nicht falsifizierbaren quadratischen Behauptungen angeht. Apropos: Was heißt eigentlich "cool" auf Altgriechisch?

                  Und an Christian: Steh doch dazu, dass Du pensionierter Altgriechischlehrer bist. Viele Schülerinnen bekommen heute noch glänzende Augen, wenn ich als Dein unwürdiger Nachfolger in der 12 auf die Zeit vor Deiner Pensionierung anspiele. Und: Ich kenne mindestens zwei Studentinnen, die in ihrer Studentenbude ein Bild über ihrem Bettchen hängen haben, darunter eine Miss-Germany mit einem IQ von 146 und eine der schönsten aller ehemaligen Klosterschülerinnen, und sich jetzt in stetigen Gedanken an Dich der Altphilologie widmen!

                  Viele runde Grüße
                  Mathias Bigge

                  --
                  http://www.selfaktuell.teamone.de/tippstricks/index.htm
                  Nicht-falsifizierbares orthopädisches Programmieren lernen!
                  1. Hallo Mathias,

                    [...]

                    *lol* -- you made my day ;)

                    Gruesse,
                     CK

                  2. Hi,

                    hab' mich wieder etwas beruhigt.   :-)

                    alter Sozailzugehörigkeitsspekulant ;-) Ich hoffe, man kann von Deinem Nick nicht auf entsprechende Gruppenzugehörigkeiten schließen?

                    Nein, denn Bekannte und Freunde nennen mich gelegentlich auch mal Lude, im schlimmeren Fall Luddie und oft auch beim richtigen Vornamen Ludger.

                    Deien Argumentation ist humorlos, zu orthogonal und letztlich nur emotional nachvollziehbar.
                    Orthogonale Argumente nur emotional nachvollziehbar - Du meinst vielleicht orthopädisch? Oder hast Du rechteckige Emotionen?

                    Ich meinte tatsächlich orthopädisch, hatte das Wort aber gerade nicht parat.

                    Meine Argumemntation bleibt unwiderlegt (weil letztendlich, wie ich einräumen muss, auch nicht falsifizierbar).  :-)
                    Herrlich, nicht falsifizierbare Argumentationen, wenn das der gute Popper lesen müsste, aber vielleicht fehlen Deinen Argumentationen einfach nur ganz entscheidend - die Argumente?

                    Popper sagte sowas in der Richtung.   :-)

                    PS: Warum eigentlich so uncoole Statements?

                    Sicher ist Christian als älterer Akademiker und überlebender Altgrieche überempfindlich, was die öffentliche Demaskierung dieser unabweisbaren, nicht falsifizierbaren quadratischen Behauptungen angeht. Apropos: Was heißt eigentlich "cool" auf Altgriechisch?

                    Und an Christian: Steh doch dazu, dass Du pensionierter Altgriechischlehrer bist. Viele Schülerinnen bekommen heute noch glänzende Augen, wenn ich als Dein unwürdiger Nachfolger in der 12 auf die Zeit vor Deiner Pensionierung anspiele. Und: Ich kenne mindestens zwei Studentinnen, die in ihrer Studentenbude ein Bild über ihrem Bettchen hängen haben, darunter eine Miss-Germany mit einem IQ von 146 und eine der schönsten aller ehemaligen Klosterschülerinnen, und sich jetzt in stetigen Gedanken an Dich der Altphilologie widmen!

                    Alles gelogen, stimmt's? - Der Mann ist angehender Informatiker mit dem Hang zur Hardware?

                    Gruss,
                    Lude

  5. Die sache ist die mich stört ist folgende. Manchmal hab ich ein Problem beim homepage basteln. Ich suche im Stichwortverzeichnis von selfhtml, nutze die selfhtml suche. Beides wirft mir eine Unmenge von Text aus. Wo bei sich mein spezielles Problem in vielleicht 2 zeilen lösen lässt.

    Nun kommt für mich das Forum zum Tragen. Ich poste hier mein Problem und hoffe auf schnelle antwort. Nun muss ich mir leider oft anhören ich hätte doch besser in selfhtml oder in alten Forumsbeiträgen lesen sollen.

    Vielleicht bin ich in der hinsicht etwas bequem, ich hab keine lust stundenlang Text zu lesen, wenn mir evtl jmd. aus dem Forum helfen könnte. Manchmal muss es einfach auch schnell gehen. Und dann kommen von einigen usern Komentare solche bitterbösen komentare, wie erst lesen dann Posten. Das regt mich auf.

    Zum glück sind nicht alle hier im Forum so und das stimmt mich froh

    Liebe Grüsse

    Stefan

    1. Hallo,

      Vielleicht bin ich in der hinsicht etwas bequem, ich hab keine lust
      stundenlang Text zu lesen, wenn mir evtl jmd. aus dem Forum helfen
      könnte. Manchmal muss es einfach auch schnell gehen.

      Manchmal. Aber in erster Linie verstehen hier einige eben das Forum nicht als den Ort der schnellen Antworten. Es ist vielleicht einfach das falsche Forum, in dem Du fragst? Dann kannst Du ja nicht den "forumsgeistbeherzigern" die Schuld geben...

      "Es wird erwartet, daß bei Problemen erst einmal in SELFHTML, im Ordner Forumsarchiv oder in anderen Quellen nach einer Lösung gesucht wird."

      Das man mal(!) eine schnelle Antwort sucht oder Tomaten auf den Augen hat fällt unter Menschlichkeit und wird normalerweise geduldet: wenn man von dem betreffenden weiß, daß dies eine Ausnahme ist. Dies geht allerdings naturgemäß nicht bei Erstpostern (blöd, ich weiß) und bei Anonymen Postern. (das sind eh dann die unangenehmsten....)

      Chräcker

      1. Hallo,

        [...]

        Das man mal(!) eine schnelle Antwort sucht oder Tomaten auf den Augen hat fällt unter Menschlichkeit und wird normalerweise geduldet: wenn man von dem betreffenden weiß, daß dies eine Ausnahme ist. Dies geht allerdings naturgemäß nicht bei Erstpostern (blöd, ich weiß) und bei Anonymen Postern. (das sind eh dann die unangenehmsten....)

        auch wenn es keine direkte Antwort ist...
        Ich habe im Moment nicht so sehr die Zeit hier ins Forum zu schauen
        und wenn ich mal hier bin, dann kann ich immer nur einige Beiträge überfliegen.
        Aber in dem Abstand den ich gerade zum Forum habe, ist mir schon aufgefallen, das hier die Stimmung ganz schön ab-und(unter)-kühlt geworden ist.
        Sicher hat das auch was mit (vielleicht ? steigenden) Besucherzahlen zu
        tun. Und den vielen die sich nicht darum scheren und einfach posten
        was ihnen einfällt.
        Aber ich habe auch mal wieder einfach in den FAQs rumgelesen und finde das sie
        viel zu aufgebläht sind.
        Auch wenn man noch so guten willens ist sind die meiner Meinung nach
        entschieden zu lang.
        Das einige "alteingesessene" Selfer etwas/ziemlich genervt
        über die Newbies reagieren ist verständlich, leider der Stimmung
        nicht zuträglich und verändert den Geist des Forums der ja eigent-
        lich bewahrt werden soll. Also ist es eine Frage des Maßes
        derer die Antworten, inwieweit man die Stimmung mit einem  wütenden posting oder garkeiner Antwort (was ich genauso beschissen finde)
        vergiftet.

        nachdenkliche Grüsse

        Sonia

        1. Hallo,

          auch wenn es keine direkte Antwort ist...

          das sind doch meistens die spannensten ;-)

          Aber in dem Abstand den ich gerade zum Forum habe, ist mir schon
          aufgefallen, das hier die Stimmung ganz schön ab-und(unter)-kühlt
          geworden ist.

          Ich glaube, dies liegt zum Teil auch daran, daß die Newbiefragen immer mehr steigen. (Was nicht an den Newbies an sich liegt! was sollen die auch machen ;-)): Soooo viel neues hat es in der letzten Zeit an Entwicklung in der technik auch nicht gegeben. Jeder "alte" hier hat bereits sein Steckenpferd zur Genüge geritten, schaut ab und an mal über den Teller (wenns hoch kommt) und braucht kaum noch was zu fragen. Also nehmen die neuen scheinbar "überhand".... auch deswegen gibts da eben eine "Verständnisschere".... Auch gibts eine Menge Technikorientierte bei den Alten (also den Antwortern) die direkt so ein Zucken bekommen, wenn jemand die Schöhnheit und Rafinesse einer Trennung von Struktur und "ausschmückendes Layout" nicht direkt nachvollziehen kann, oder jemand eine Flashanimtaion allemal schöner findet als ein ausgeklügeltes css-Sperator-Konstrukt.

          Aber ich habe auch mal wieder einfach in den FAQs rumgelesen und
          finde das sie viel zu aufgebläht sind.

          vollkommen Deiner Meinung. Ich empfinde sie zu weiten Teilen geradezu als überflüssig . Und auf jedenfall als schönes Beispiel, wie man das Medium Internet nicht richtig zur Informationsübermittlung eingesetzt hat ;-) Denn: die Information kommt definitiv nicht an. Warum auch? Leute, die den "benimmteil" derselbigen lesen, brauchen ihn nicht. Leute, die ihn bräuchten, lesen ihn nicht. Beide Gruppen ignorieren den "lies zuerst die FAQ" sowieso. Gelesen wird dieselbige meist nur von denen, die sie als Postingantwort verlinken wollen.

          Chräcker

          1. Hi,

            Eure Debatte zur FAQ hat mich nachdenklich gemacht.

            Aber ich habe auch mal wieder einfach in den FAQs rumgelesen und finde das sie viel zu aufgebläht sind.
            vollkommen Deiner Meinung. Ich empfinde sie zu weiten Teilen geradezu als überflüssig . Und auf jedenfall als schönes Beispiel, wie man das Medium Internet nicht richtig zur Informationsübermittlung eingesetzt hat ;-) Denn: die Information kommt definitiv nicht an. Warum auch? Leute, die den "benimmteil" derselbigen lesen, brauchen ihn nicht. Leute, die ihn bräuchten, lesen ihn nicht. Beide Gruppen ignorieren den "lies zuerst die FAQ" sowieso. Gelesen wird dieselbige meist nur von denen, die sie als Postingantwort verlinken wollen.

            Stimmt leider einerseits, andererseits gibt es aber auch immer wieder neue Wunschlisten, welche Standardlösung noch in die FAQ sollte, um das Forum zu entlasten.

            Könnte eine locker geschriebene Kurzfassung helfen?

            Viele Grüße
            Mathias Bigge

            1. Hallo,

              andererseits gibt es aber auch immer wieder neue Wunschlisten,
              welche Standardlösung noch in die FAQ sollte, um das Forum zu
              entlasten.

              ...eine FAQ beduetet ja nicht, so wie sie bisher zum teil aufgebaut ist, daß dort Fragen beantwortet werden, die sich ein Besucher hier "mal besser stellen sollte", sondern eben wirklich, daß Fragen beantwortet werden, *die* (sich) Besucher stellen. Also Fragen wie "warum darf ich nicht eine frage in 5 Minuten Intervallen wiederholen" fragt sich ja niemand. Die, die es wissen, machen es nicht, die anderen sind eh zu deppert um auf diese Frage zu kommen.

              Eine echte FAQ wäre also in der tat eine liste von fragen, die hier "exakt" so immer wieder gestellt wird. Diese Listungen gibts ja aber in der Tips-und-Tricks Sektion, zum teil in der Spezial-beitrag-Sektion und wie die Ecken alle lauten, die sich so langsam hier im seöf-Raum angesammelt haben.

              Für mich könnte fast die ganze FAQ weg bzw umverteilt werden. Im strengsten Sinne ist das ganze selfhtml eine FAQ....

              Chräcker

              1. Hallo Chräcker,

                Für mich könnte fast die ganze FAQ weg bzw umverteilt werden. Im strengsten Sinne ist das ganze selfhtml eine FAQ....

                Hmmmm. Ich weiß nicht sorecht... Ich habe die FAQ ganz am Anfang gelesen (und dann erst einmal einen Schrecken bekommen *g*) und hab' mich dann ganz gut hier eingefunden. Gerade der Tipp "Warum sollte ich mich vor dem Abschicken eines Postings fragen, ob dieses wirklich sinnvoll ist?" war sehr sehr nützlich und hat diesem Forum so einiges an Dummheiten erspart. (nicht technisch, sondern menschlich gesehen)

                Grüße,

                Christian

                --
                Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
                                      -- Albert Einstein
                1. Hallo,

                  naaa gut, dann lassen wir den einen Punkt halt drin ,-))))

                  Aber ernster: das hätte ich nicht gedacht, daß die jemand wirklich als echte Orinetierungshilfe liest. (Hab ich eben jetzt gelernt).... Nur, ob das viele sind? (keine ganz rethorische frage....) Aber gut, wieder was gelernt....

                  Chräcker

                2. Hallo Christian,

                  Hmmmm. Ich weiß nicht sorecht... Ich habe die FAQ ganz am Anfang gelesen (und dann erst einmal einen Schrecken bekommen *g*) und hab' mich dann ganz gut hier eingefunden. Gerade der Tipp "Warum sollte ich mich vor dem Abschicken eines Postings fragen, ob dieses wirklich sinnvoll ist?" war sehr sehr nützlich und hat diesem Forum so einiges an Dummheiten erspart. (nicht technisch, sondern menschlich gesehen)

                  ich möchte mich Dir vollumfänglich anschließen.

                  Die wenigen Leute, die tatsächlich die FAQ lesen, bevor sie etwas posten, sollen eine FAQ vorfinden, die _ihre_ Fragen beantworten. Denn _diese_ Leute will ich im Forum drin haben - denen möchte ich jede mögliche Hilfestellung für den "Erstkontakt" geben.

                  Die Bedürfnisse derjenigen, welche die FAQ (in welcher Länge auch immer sowieso) nicht lesen werden (das ist nämlich eine Frage der Einstellung, nicht des Zeitaufwands: Wenn ich plane, in einem solchen Form mehr als eine Frage lang zu bleiben, ist das vorherige Lesen der FAQ immer eine gute Idee), ausgerechnet innerhalb der FAQ berücksichtigen zu wollen, finde ich absurd.

                  Viele Grüße
                        Michael

                  1. Hi,

                    ein Beitrag von einem, der sicherlich schon jede Zeile der FAQs gelesen hat, aber nicht alles im Gedächtnis halten kann.

                    Hmmmm. Ich weiß nicht sorecht... Ich habe die FAQ ganz am Anfang gelesen (und dann erst einmal einen Schrecken bekommen *g*) und hab' mich dann ganz gut hier eingefunden. Gerade der Tipp "Warum sollte ich mich vor dem Abschicken eines Postings fragen, ob dieses wirklich sinnvoll ist?" war sehr sehr nützlich und hat diesem Forum so einiges an Dummheiten erspart. (nicht technisch, sondern menschlich gesehen)

                    ich möchte mich Dir vollumfänglich anschließen.

                    Die wenigen Leute, die tatsächlich die FAQ lesen, bevor sie etwas posten, sollen eine FAQ vorfinden, die _ihre_ Fragen beantworten. Denn _diese_ Leute will ich im Forum drin haben - denen möchte ich jede mögliche Hilfestellung für den "Erstkontakt" geben.

                    Die Qualität der Forumsbeiträge, und darum scheint es zu gehen, hängt immer nur _auch_ von den Forumsregeln ab. Die Wirklichkeit entscheidet in diesem komplexen System was an Beiträgen "hochkommt".

                    Die Bedürfnisse derjenigen, welche die FAQ (in welcher Länge auch immer sowieso) nicht lesen werden (das ist nämlich eine Frage der Einstellung, nicht des Zeitaufwands: Wenn ich plane, in einem solchen Form mehr als eine Frage lang zu bleiben, ist das vorherige Lesen der FAQ immer eine gute Idee), ausgerechnet innerhalb der FAQ berücksichtigen zu wollen, finde ich absurd.

                    Rein formale Argumentation, welche in 100% lenkbaren Systemen greift. - Was ist schon absurd?   :-)

                    => Eine Regel-FAQ muss primär erst einmal funktionieren und die gewünschte Wirkung erzielen. Funktioniert Sie nicht, und so empfindest Du das möglicherweise, dann muss man Sie anpassen oder Deine Bedürfnisse. Und das wäre vielleicht etwas für Psychologen und Soziologen, weniger für rechtwinklige Denker.

                    Gruss,
                    Lude

                    1. Hi Lude,

                      => Eine Regel-FAQ muss primär erst einmal funktionieren und die gewünschte Wirkung erzielen. Funktioniert Sie nicht, und so empfindest Du das möglicherweise, dann muss man Sie anpassen oder Deine Bedürfnisse. Und das wäre vielleicht etwas für Psychologen und Soziologen, weniger für rechtwinklige Denker.

                      Ganz im Gegenteil: Ich finde, daß die FAQ durchaus 'funktioniert'. Ich rechne gar nicht damit, daß sie von Leuten gelesen wird, die vorausschauendes Denken beim Betreten einer neuen Umgebung nicht als natürlichen Bestandteil ihrer Verhaltensweise betrachten. Deshalb möchte ich sie auf die tatsächlichen potentiellen Leser optimiert haben, nicht auf diejenigen, die sie ohnehin nicht lesen werden. Und deshalb ist mir der momentane Zustand (umfangreich, aber mühsam) lieber als irgend eine "geschrumpfte" Variante.

                      Viele Grüße
                            Michael

                      1. Hallo, Michael,

                        Ganz im Gegenteil: Ich finde, daß die FAQ durchaus 'funktioniert'. Ich rechne gar nicht damit, daß sie von Leuten gelesen wird, die vorausschauendes Denken beim Betreten einer neuen Umgebung nicht als natürlichen Bestandteil ihrer Verhaltensweise betrachten. Deshalb möchte ich sie auf die tatsächlichen potentiellen Leser optimiert haben, nicht auf diejenigen, die sie ohnehin nicht lesen werden. Und deshalb ist mir der momentane Zustand (umfangreich, aber mühsam) lieber als irgend eine "geschrumpfte" Variante.

                        Aha, da hatte ich Dich nicht richtig verstanden. Du meinst also, dass es a) wichtig ist, dass die FAQs/Forumsregeln "funktionieren" b) dass sie funktionieren und c) dass deren voraussichtliches "Funktionieren" nicht durch, sagen wir mal logisch rationales Denken, also mithilfe von  "Fallunterscheidungen" vorhergesagt werden kann.

                        Ob Du c) zustimmst weiss ich allerdings nicht so genau; hast Du doch vor einiger Zeit die Existenzberechtigung laufender Finanzdienstleistungssoftware von deren Entwicklungsstandards abhängig gemacht und nicht, wie das möglicherweise auch völlig verfehlt geschieht vom Geld, das man mit ihr verdient.   :-)

                        Gruss,
                        Lude

                        PS: Ich hatte zudem befürchtet nicht zu den Leuten zu gehören, die Du im Forum "'drin haben" möchtest. Danke für das Nicht-Setzen eines "Lude-Filters"!

                        1. Hi,

                          also man könnte es so kurzfassen,
                          das IMHO 2 verschiedene Ziele mit der FAQ
                          verfolgt werden. Eins davon finde ich
                          FAQ zweckentfremdend.

                          1. Ziel: Eine Auflistung der meist gestellten Fragen
                          die jedem Forumaner nach dem 50. mal sicher auf den
                          Keks gehen.

                          2. Ziel: Eine Aufstellung von "Benimmregeln"

                          2. Hat durchaus seine Existenzberechtigung, gehört aber über-
                          haupt nicht in eine FAQ sondern in sowas wie "Verhaltensregeln"
                          von mir aus auch VRGs ;-)))

                          Der Witz ist eigentlich, das die eigentliche FAQ unter
                          Q32 als unterpunkte zu finden sind... Nee wenn schon alles in einem
                          "Brei" sein soll(muß?) dann gehört das m.E. unter die obersten
                          Punkte damit man es gleich findet.
                          was meint ihr?

                          Gruß Sonia

                        2. Hi Lude,

                          Aha, da hatte ich Dich nicht richtig verstanden. Du meinst also, dass es a) wichtig ist, dass die FAQs/Forumsregeln "funktionieren"

                          mir ist es wichtig genug, um mich an einer Diskussion über sie zu beteiligen.

                          b) dass sie funktionieren

                          Gemäßt meiner (irrelevanten) Definition, ja.

                          und c) dass deren voraussichtliches "Funktionieren" nicht durch, sagen wir mal logisch rationales Denken, also mithilfe von "Fallunterscheidungen" vorhergesagt werden kann.

                          Mir ist nicht bewußt, wo ich das behauptet hätte.

                          Ich denke im Gegenteil: Wenn ich mich mit einem Forum-Leser eine Weile unterhalten würde, könnte ich mit recht ordentlicher Wahrscheinlichkeit vorhersagen, ob er ein potentieller FAQ-Leser ist.
                          Der praktische Nutzwert dieser Aussage ist allerdings vernachlässigbar.

                          Ob Du c) zustimmst weiss ich allerdings nicht so genau; hast Du doch vor einiger Zeit die Existenzberechtigung laufender Finanzdienstleistungssoftware von deren Entwicklungsstandards abhängig gemacht und nicht, wie das möglicherweise auch völlig verfehlt geschieht vom Geld, das man mit ihr verdient.   :-)

                          Ups - da hätte mir jetzt gefallen, wenn Du einen Archiv-Link gesetzt hättest.

                          Ich denke jedoch, daß beides nicht unabhängig voneinander gesehen werden kann ... die Menge des erzielbaren finanziellen Ertrags einer Online-Dienstleistung hat sich in den letzten tausend Jahren durch die plötzliche technische Verfügbarkeit von Online-Zugängen, die entsprechende Schulung der Anwender etc. natürlich dramatisch geändert. Mangels augenblicklicher Verfügbarkeit meines angeblichen Zitats bin ich nicht in der Lage, zu beurteilen, wie weit ich den Begriff "Entwicklungsstandard" an der betreffenden Stelle gefaßt habe ...

                          PS: Ich hatte zudem befürchtet nicht zu den Leuten zu gehören, die Du im Forum "'drin haben" möchtest. Danke für das Nicht-Setzen eines "Lude-Filters"!

                          Solange mir die Forum-Software bei der Filterung der Autoren nur eine einzige Blacklist erlaubt und deren Änderung zudem jeweils die Verwendung des Konfigurations-Dialogs erfordert (siehe Diskussion an anderer Stelle im aktuellen Forum), würde die Verwendung dieser Blacklist bedeuten, daß ich einer so markierten Person die Fähigkeit absprechen würde, in der Zukunft Postings zu verfassen, welche zu lesen mich interessieren könnte. Das wäre eine erschreckend endgültige Aussage. Folglich ist meine Poster-Blacklist derzeit leer.

                          Überhaupt ist es nicht wahrscheinlich, daß eine Blacklist meinen "Arbeitsstil" im Forum jemals unterstützen könnte. Poster, die ich ausblenden wollen würde, müßten hinreichend dauerhaft und unter Verwendung einer konstanten Poster-Identität im Forum auftreten, um den Eintrag in der Blacklist überhaupt zu rechtfertigen. Und die Wahrscheinlichkeit, auf diese Weise eine mehr als minimale Anzahl von Postings auszublenden, ist gar nicht arg hoch.

                          Umgekehrt basiert die Verwendung einer Whitelist m. E. auf der Erkenntnis, daß die betreffenden Personen ihre "Qualifikation" hierfür auf absehbare Zeit nicht verlieren werden und gleichzeitig hinreichend oft posten werden, um die Definition eines entsprechenden Filters zu rechtfertigen - diese Wahrscheinlichkeit ist bei Regulars vermutlich ziemlich hoch, weil aufgrund der diesem Forum zugrundeliegenden Denkweise die Posting-Stile etlicher Regulars hinreichend kompatibel zueinander sein dürften. Diese Idee ist mir also sehr sympathisch - ich erwarte ein gutes Preis/Leistungs-Verhältnis bei ihrer Anwendung.

                          Viele Grüße
                                Michael

                      2. Hallo!

                        Ganz im Gegenteil: Ich finde, daß die FAQ durchaus 'funktioniert'.

                        Das kommt drauf an wie Du 'funktionieren' definierst und was man sich von den FAQ verspricht. Ich finde, wie einige andere hier, den Namen 'FAQ' schlichtweg falsch, da es nunmal keine FAQ sind! Ich habe die FAQ am Anfang auc nicht gelesen(wie Du vermutlich auch so erraten hättest *g*), da ich schon einige Foren, eher Boards kannte, und da gibt es auch unmengen von FAQs, und da steht immer dasselbe drin und fast immer nur Fragen zur Bedienung des Boards. Schon beim 5 Forum/Board habe ich aufgehört die zu lesen, halt nur wenn ich eine Frage hatte, und _dazu_ sind FAQ da, habe ich eine Frage kann ich am Anfang davon ausgehen das ich nicht der einzige "Anfänger" bin mit der Frage, also gucke ich in der Sammlung der "Frequently Asked Questions". _Dazu_ sind FAQ da. Das was wir hier haben ist hervorragend, aber das sind keine FAQ! Das da derartige Informationen drinstehen, woher soll man das wissen wenn die Bezeichnung dies nicht vermuten läßt? Die FAQ ist vom Aufbau und vom Inhalt wirklich perfekt, nur die Bezeichnung, sollte man vielleicht "Verhaltensregeln", oder "Forums-Regeln" nennen, aber das ist auch nicht gut, man müßte was besseres finden.

                        Ich rechne gar nicht damit, daß sie von Leuten gelesen wird, die vorausschauendes Denken beim Betreten einer neuen Umgebung nicht als natürlichen Bestandteil ihrer Verhaltensweise betrachten. Deshalb möchte ich sie auf die tatsächlichen potentiellen Leser optimiert haben, nicht auf diejenigen, die sie ohnehin nicht lesen werden. Und deshalb ist mir der momentane Zustand (umfangreich, aber mühsam) lieber als irgend eine "geschrumpfte" Variante.

                        Aber was hast Du groß davon? Die Leute die sich vorm ersten Posting durch die FAQ "quälen", würden vermutlich schon von der Persönlichkeit her die meisten Fehler vermeiden, die in der FAQ beschrieben sind. Und die Leute würden sich auch "Verhaltensregeln" durchlesen, vielleicht sogar eher, da sie unter "FAQ" standard-board FAQ vermuten könnten. Es sind 2 Ziele die die FAQ verfolgt, das eine hast Du genannt, das andere wäre aber noch bestimmte Postings von vornherein aus dem Forum zu halten, und das erreichst Du durch die augenblicklichen FAQ überhaupt nicht. Man müßte für diese Leute die wichtigsten und nervigst Regeln "kurz und knackig" zusamenfassen, und am besten vor jedem Posting anzeigen, von jemandem der nicht registriert ist, und auch bei der Registrierung. Das würde vielleicht ein wenig helfen, vielleicht, viel vermutlich nicht. Dazu würde ich noch für eine Fach-FAQ plädieren, mit "2 Frames gleichzeitig ändern...". also insgesamt die FAQ in 3Teile teilen:

                        • Verhaltensregeln
                        • Fach-FAQ
                        • kurze Benimmregeln für Neulinge

                        So wäre meines Erachtens alles abgedeckt.

                        Viele Grüße
                        Andreas

                        PS: und die Fach-FAQ könnt man langsam schön ausbauen, zumindest finde ich das die Informationen im Selfrauem etwas sehr weit verteilt sind!

                        1. Hi Andreas,

                          Ich habe die FAQ am Anfang auc nicht gelesen(wie Du vermutlich auch so erraten hättest *g*),

                          dafür hast Du Dich aber hervorragend entwickelt.

                          Die Leute die sich vorm ersten Posting durch die FAQ "quälen", würden vermutlich schon von der Persönlichkeit her die meisten Fehler vermeiden, die in der FAQ beschrieben sind.

                          Wahr. Aber sie werden dem Anbieter auch für die komplette FAQ dankbar sein, weil die ihnen die Arbeit abnimmt, die konkrete Ausprägung dieser Regeln zu erraten (bzw. durch eine Beobachtungsphase zu lernen).

                          Und die Leute würden sich auch "Verhaltensregeln" durchlesen,

                          Ich wollte, ich wäre mir da so sicher wie Du.

                          das andere wäre aber noch bestimmte Postings von vornherein aus dem Forum zu halten, und das erreichst Du durch die augenblicklichen FAQ überhaupt nicht.

                          Das erreiche ich durch keine Form der FAQ - weil diejenigen, die ich "aus dem Form halten" wollen würde, keine dieser Formen lesen würden. Der inzwischen existierende Posting-Assistent, aufgemotzt um Links auf die entsprechenden FAQ-Abschnitte für jeden "Verstoß", ist ein Weg, diejenigen Leute zu erreichen, die es wirklich betrifft.

                          Man müßte für diese Leute die wichtigsten und nervigst Regeln "kurz und knackig" zusamenfassen, und am besten vor jedem Posting anzeigen, von jemandem der nicht registriert ist, und auch bei der Registrierung.

                          Die "Haben-wollen"-Poster registrieren sich nicht. Das einzige, was die definitiv tun, ist posten ... und genau dort greift der "Assistent".

                          • Verhaltensregeln
                          • Fach-FAQ
                          • kurze Benimmregeln für Neulinge

                          Gegen eine bessere Gliederung der heutigen FAQ habe ich nichts einzuwenden. Die Hoffnung, daß sie dadurch signifikant mehr Leser bekommen könnte, teile ich jedoch nicht.

                          PS: und die Fach-FAQ könnt man langsam schön ausbauen, zumindest finde ich das die Informationen im Selfraum etwas sehr weit verteilt sind!

                          Du weißt, was man im Self-Raum alles durchsuchen kann?

                          Viele Grüße
                                Michael

                          1. Hallo!

                            dafür hast Du Dich aber hervorragend entwickelt.

                            Danke *g*, habe vermutlich würde ich heut sowas auch lesen, aber jetzt kenne ich sie ja auch. Was ich nur sagen wollte ist das FAQ nicht der Richtige Begriff ist, da es in jedem Forum/Board FAQs gibt in denen eher andere Dinge stehen! Daher weiß vermutet man hinter den FAQ hier evtl nicht das was da steht. Ich meine die große Masse der Poster und Neulinge!

                            Wahr. Aber sie werden dem Anbieter auch für die komplette FAQ dankbar sein, weil die ihnen die Arbeit abnimmt, die konkrete Ausprägung dieser Regeln zu erraten (bzw. durch eine Beobachtungsphase zu lernen).

                            Das sind aber wirklich wenig Leute die so reagieren, so schade das ist! Man denkt ja erstmal weniger an die Comunitiy, sondern man hat ein Problem was eijen vielleicht schon ne ganze Zeit nervt!

                            Ich wollte, ich wäre mir da so sicher wie Du.

                            Leute die wirklich an derartigen Regeln interessiert sind, die lesen doch auch das, wenn da steht:

                            • Foren-Regeln(bite vorher lesen)
                            • Fach-FAQ(häufig gestellt Fragen zu HTML, Javascript & Co)

                            dann liest der Mensch doch beides, oder, bei einer konkreten Frage erstmal die Fach-FAQ, und bevor er eien Frage stellt die Regeln. ZUmindest ich fänd das so erheblich klarer, FAQ alleien wirkt wie ich finde viel zu unscheinbar und sieht nach einer Standard-Board-FAQ aus(der Link)!

                            Das erreiche ich durch keine Form der FAQ - weil diejenigen, die ich "aus dem Form halten" wollen würde, keine dieser Formen lesen würden. Der inzwischen existierende Posting-Assistent, aufgemotzt um Links auf die entsprechenden FAQ-Abschnitte für jeden "Verstoß", ist ein Weg, diejenigen Leute zu erreichen, die es wirklich betrifft.

                            Das befürchte ich allerdings auch, leider.

                            Die "Haben-wollen"-Poster registrieren sich nicht. Das einzige, was die definitiv tun, ist posten ... und genau dort greift der "Assistent".

                            Wenn der das denn alles kann - Respekt! Das wäre ein absolutes Sahnestück für das Forum, das würde vermutlcih dei Atmosphäre deutlich verbessern. Nur fühlen sich dann _einige_ Leute auf den Schlips getreten und fühlen sich unrechtmäßig bevormundet und werden böse, wei auch immer das sich dann auswirkt. Man muß den Assistenten sehr gut durchdenken, aber ich habe da vollstes Vertrauen in die üblichen Verdächtigen ;-)

                            • Verhaltensregeln
                            • Fach-FAQ
                            • kurze Benimmregeln für Neulinge

                            Gegen eine bessere Gliederung der heutigen FAQ habe ich nichts einzuwenden. Die Hoffnung, daß sie dadurch signifikant mehr Leser bekommen könnte, teile ich jedoch nicht.

                            ich könnte mir schon vorstekken das vor allem ein paar Standard-Fragen abgehalten würden, bzw. schnell als durch ein Posting geklärt würden!

                            Du weißt, was man im Self-Raum alles durchsuchen kann?

                            _ich_ weiß das, aber einige anere nicht. Vor allem bringt Dir die tollste Suche  nichts, wenn Du keien Begriffe weißt wonach Du suchen sollst, das passiert Dir nicht, mir auch immer seltener, aber vielen Anfängern, udn da ist das Klicken durch ein strukturierte Fach-FAQ doch erheblich Ergonomischer, wenn man das so nenne kann, vielleicht eher Benutzerfeundlicher, vor allem für Anfänger!

                            Grüße
                            Andreas

                            1. Hi Andreas,

                              Leute die wirklich an derartigen Regeln interessiert sind, die lesen doch auch das, wenn da steht:

                              • Foren-Regeln(bite vorher lesen)
                              • Fach-FAQ(häufig gestellt Fragen zu HTML, Javascript & Co)
                                dann liest der Mensch doch beides

                              wie gesagt: Gegen eine redaktionelle Überarbeitung all dessen, was bisher in der FAQ steht, spricht meiner Meinung nach nicht viel (lediglich, daß im Archiv tausende von Verweisen auf die FAQ stehen). Hoffnungen bezüglich einer dadurch wesentlich verbesserten Zugriffsrate teile ich jedoch nicht.

                              Die "Haben-wollen"-Poster registrieren sich nicht. Das einzige, was die definitiv tun, ist posten ... und genau dort greift der "Assistent".
                              Wenn der das denn alles kann - Respekt! Das wäre ein absolutes Sahnestück für das Forum, das würde vermutlcih dei Atmosphäre deutlich verbessern.

                              Der "Assistent" ist offenbar bereits im Einsatz. (Mir hat er neulich weis zu machen versucht, ein Posting bestehend aus einer Zeile Zitat, einer Leerzeile und einer Zeile Antwort enthalte "mehr als 50% Zitatzeilen" ... ;-)
                              Daß Du dies nicht bei jedem Deiner Postings spürst, spricht für Deine Posting-Qualität.

                              Nur fühlen sich dann _einige_ Leute auf den Schlips getreten und fühlen sich unrechtmäßig bevormundet und werden böse, wei auch immer das sich dann auswirkt.

                              Wer sich gerne beleidigt fühlt, findet immer einen Anlaß dafür.

                              Du weißt, was man im Self-Raum alles durchsuchen kann?
                              _ich_ weiß das, aber einige anere nicht.

                              Alleine das ist schon ein Fehler, finde ich. Wenn ein Portal schon eine Suchfunktion anbietet, dann sollte man wenigstens verstehen, was diese zu leisten in der Lage ist.

                              Vor allem bringt Dir die tollste Suche  nichts, wenn Du keien Begriffe weißt wonach Du suchen sollst,

                              Sie dann auch aktiv zu nutzen, das ist eine andere Sache, okay.

                              Aber selbst wenn Du mit der Suche nichts findest, hat sie Dir doch immerhin durch ihr Suchformular gezeigt, daß es in diesem Portal hier so etwas wie eine Link-Liste und eine Sammlung von Feature-Artikeln gibt - also nicht 'nur' SelfHTML allein.

                              Konsequenterweise sollten deshalb auch die Tips & Tricks durchsuchbar sein ... und sei es nur, weil sie dadurch auch in der Suchmaschine sichtbar sind (viele Besucher, die das Forum kennen, gehen vielleicht nur selten auf die SelfAktuell-Startseite). Wenn diese neue Artikelform sich an die allgemeinen Format-Vorgaben der übrigen Dokumente des Self-Portals hält, dann sollte es leicht sein, einen der bestehenden Indexer entsprechend anzupassen ... und das Hinzufügen einer weiteren Indexdatei zu such.pl ist nun auch keine Zauberei.
                              Bei der Gelegenheit könnte mal jemand die riesige Indexdatei für 2002 wenigstens in zwei Halbjahre unterteilen ... ach ja, und 2003 steht vor der Tür, da wird auch wieder eine Anpassung fällig sein ...

                              Viele Grüße
                                    Michael

                              1. Hi Michael,

                                Konsequenterweise sollten deshalb auch die Tips & Tricks durchsuchbar sein ... und sei es nur, weil sie dadurch auch in der Suchmaschine sichtbar sind (viele Besucher, die das Forum kennen, gehen vielleicht nur selten auf die SelfAktuell-Startseite). Wenn diese neue Artikelform sich an die allgemeinen Format-Vorgaben der übrigen Dokumente des Self-Portals hält, dann sollte es leicht sein, einen der bestehenden Indexer entsprechend anzupassen ... und das Hinzufügen einer weiteren Indexdatei zu such.pl ist nun auch keine Zauberei.

                                ganz grosse Zustimmung.
                                Da wird die "Umsetzung", der Kochbuchbereich abgedeckt. (Stimmt doch hoffentlich, was ich da geschrieben habe?!)
                                Gerade da suchen viele dullere Entwickler, die etwas vor Augen haben müssen und abstraktem Denken eher abgeneigt sind, nach Stoff.

                                Gruss,
                                Lude

                              2. Hallo

                                wie gesagt: Gegen eine redaktionelle Überarbeitung all dessen, was bisher in der FAQ steht, spricht meiner Meinung nach nicht viel (lediglich, daß im Archiv tausende von Verweisen auf die FAQ stehen).

                                Die könnte man ja entweder mit einem Script ändern, oder vielleicht besser mit einer Rewrite-Rule umleiten. Und wo "wir" schonmal dabei sind, vielleicht sollte man so etwas auch mit den Links zu Postings im aktuellen Forum machen!

                                Hoffnungen bezüglich einer dadurch wesentlich verbesserten Zugriffsrate teile ich jedoch nicht.

                                Ich weiß es nicht.

                                Der "Assistent" ist offenbar bereits im Einsatz. (Mir hat er neulich weis zu machen versucht, ein Posting bestehend aus einer Zeile Zitat, einer Leerzeile und einer Zeile Antwort enthalte "mehr als 50% Zitatzeilen" ... ;-)
                                Daß Du dies nicht bei jedem Deiner Postings spürst, spricht für Deine Posting-Qualität.

                                Das ist mir auch schonmal passiert, wobei es mich doch wundert das es Dir passiert denn Du "haust" Dir ja immer zig Umbrüche da rein, das mache ich nicht ;-)

                                Wer sich gerne beleidigt fühlt, findet immer einen Anlaß dafür.

                                Sehe ich absolut nicht so. Es geht nicht darum das die Leute "Streit suchen", sondern sie erwarten hier ein "cooles Board" wie jedes ander auch, sicher wollen die meisten hier das nicht sein, aber wenn den Leuten zu viele Vorschriften aufgezwungen werden befürchte ich das es mehr zu Trotz-Reaktionen auf diesen Mechanismus kommt, "wie sch... seid ihr eigentlich... Zensur...", halt sowas, was sonst vermutlich ausbleiben würde, wobei man ja auch das durch den Assistenten abfangen könnte ;-)

                                Alleine das ist schon ein Fehler, finde ich. Wenn ein Portal schon eine Suchfunktion anbietet, dann sollte man wenigstens verstehen, was diese zu leisten in der Lage ist.

                                Du gehst immer von deinem "Wunsch-Poster" aus, aber ein erheblicher Teil der Poster hier ist nicht so wie Du es gerne hättest. Wenn ich alles für ganz bestimmt Leute mit ganz bestimmtem Charakter und Kenntnisstand auslege, dann habe ich dafür im Forum entsprechend viele Fragen, die bei mehr Rücksichtnahme auf gerade die Fragesteller vermutlich nicht, oder nicht in dem Ausmaß gekommen wären.
                                Es geht ja auch ein bisschen darum "nervige" Threads aus dem Forum fernzuhalten, und nervige Threads kommen nunmal von Leuten auf Die Du keine Rücksicht nehmen willst.

                                Sie dann auch aktiv zu nutzen, das ist eine andere Sache, okay.

                                Was soll man sonst? Ich denke genau das ist ein Hauptproblem vieleer Anfänger, man kennt keine Fachbegriffe oder Funktionsnamen... nach denen man suchen könnte. Und einige Leute haben noch nie wirklich erfahren was eine Suche bringen kann, viele denken schllichtweg nicht daran, das andere Leute vielleicht schonmal das selbe Problem hatten?!

                                Aber selbst wenn Du mit der Suche nichts findest, hat sie Dir doch immerhin durch ihr Suchformular gezeigt, daß es in diesem Portal hier so etwas wie eine Link-Liste und eine Sammlung von Feature-Artikeln gibt - also nicht 'nur' SelfHTML allein.

                                Ja, aber auch darauf muß man erst mal kommen!

                                Konsequenterweise sollten deshalb auch die Tips & Tricks durchsuchbar sein ... und sei es nur, weil sie dadurch auch in der Suchmaschine sichtbar sind (viele Besucher, die das Forum kennen, gehen vielleicht nur selten auf die SelfAktuell-Startseite). Wenn diese neue Artikelform sich an die allgemeinen Format-Vorgaben der übrigen Dokumente des Self-Portals hält, dann sollte es leicht sein, einen der bestehenden Indexer entsprechend anzupassen ... und das Hinzufügen einer weiteren Indexdatei zu such.pl ist nun auch keine Zauberei.

                                Jaja, wie siehts eigentlich mit Danielas Suche aus? Kann man da irgendwo was zu nachlesen oder sehen? Würd mich echt interessieren. Vermutlich könnt Ihr es euch nicht erlauben so einen großen Index im RAM zu halten, oder? Wie um Himmelswillen bekommt Ihr das dann peformant? Das ist mir wirklich ein Rätsel! Das größte Rätsel überhaupt ist sowieso Google, wie das funktioniert.... Wahnsinn. Weißt Du was Google für eine Datenbank verwendet, oder keine Datenbank?

                                Grüße
                                Andreas

                                1. Hi Andreas,

                                  Die könnte man ja entweder mit einem Script ändern, oder vielleicht besser mit einer Rewrite-Rule umleiten. Und wo "wir" schonmal dabei sind, vielleicht sollte man so etwas auch mit den Links zu Postings im aktuellen Forum machen!

                                  +1. Stell' doch mal 'nen Feature-Request ...

                                  Das ist mir auch schonmal passiert, wobei es mich doch wundert das es Dir passiert denn Du "haust" Dir ja immer zig Umbrüche da rein

                                  Jetzt nicht mehr. Seitdem ich Mozilla mit aktivem CSS nehmen und die Vorschau verwenden kann ... die neue Forum-Software hat meine Posting-Gewohnheiten durchaus verändert.

                                  Du gehst immer von deinem "Wunsch-Poster" aus, aber ein erheblicher Teil der Poster hier ist nicht so wie Du es gerne hättest.

                                  Ich sehe die Benutzung der Suche genauso wie die Benutzung der FAQ: Jeder sollte sie benutzen, nur wenige werden es tatsächlich tun. Und auf die tatsächlichen Anwender möchte ich die Funktionalität ausgelegt sehen.
                                  Wer von sich aus auf die Idee kommt, etwas zu suchen, der sollte _dort_ den Hinweis bekommen, daß es die Tips & Tricks gibt.

                                  Sie dann auch aktiv zu nutzen, das ist eine andere Sache, okay.
                                  Was soll man sonst?

                                  Beispielsweise merken, daß es im Self-Raum noch andere Dokumentationen gibt.

                                  Wer mit einer Suchmaschine nicht gut umgehen kann und SelfAktuell bisher nicht als Navigationswurzel verstanden hat, erfährt auch bei einem gescheiterten Versuch einer Suche, daß es weitere Dokumente gibt, die es wert wären, mal einen Blick hinein zu werfen.

                                  Ich denke genau das ist ein Hauptproblem vieler Anfänger, man kennt keine Fachbegriffe oder Funktionsnamen... nach denen man suchen könnte.

                                  Dafür habe ich Verständnis. Und gerade deshalb sollte die Suche auf die Bedürfnisse dieser Anwender eingehen.
                                  Einen Königsweg, wie das am besten zu realisieren wäre, habe ich allerdings nicht anzubieten. Wenn ich selbst etwas suche, dessen exakte Bezeichnung ich nicht kenne, dann gebe ich eben unschärfere Begriffe an, dafür aber mehr. (Deshalb kann die Self-Suche ein AND.)

                                  Und einige Leute haben noch nie wirklich erfahren was eine Suche bringen kann, viele denken schllichtweg nicht daran, das andere Leute vielleicht schonmal das selbe Problem hatten?!

                                  Wer im Zeitalter von Google nicht mit einer Suchmaschine umgehen kann, hat überall im WWW Probleme - nicht nur im Self-Portal. Das ist also das erste, was man lernen sollte. (Ja, ich bin _für_ den Internet-Führerschein ... ;-)

                                  Aber selbst wenn Du mit der Suche nichts findest, hat sie Dir doch immerhin durch ihr Suchformular gezeigt, daß es in diesem Portal hier so etwas wie eine Link-Liste und eine Sammlung von Feature-Artikeln gibt - also nicht 'nur' SelfHTML allein.
                                  Ja, aber auch darauf muß man erst mal kommen!

                                  Es reicht, wenn man die Augen offen hat, während man im Formular seine Kreuzchen setzt.

                                  Jaja, wie siehts eigentlich mit Danielas Suche aus?

                                  Tja, da weiß ich leider nicht mehr als Du.

                                  Vermutlich könnt Ihr es euch nicht erlauben so einen großen Index im RAM zu halten, oder?

                                  Keine Ahnung. Deshalb finde ich Deine Experimente mit mySQL ja so wertvoll. Denn das Prinzip ist ja problemlos auch ohne FULLTEXT verwendbar: Stell Dir einfach vor, Du hättest eine zusätzliche Tabelle mit der Abbildung von Wort auf Posting-ID und würdest über die Worte einen non-unique Index legen ... ich verwendet eine solche Implementierung, und ich habe etwa 20 Millionen Einträge in dieser Tabelle.

                                  Wie um Himmelswillen bekommt Ihr das dann performant?

                                  Es muß nicht alles im RAM liegen. Es reicht, wenn pro Zugriff nur eine kleine Menge an Seiten ins RAM eingelagert werden müssen. Und Baumstrukturen sind ein Mittel, dies zu erreichen: Wenn die Komplexität bei 100000 Postings von linear auf logarithmisch sinkt, kannst Du einen Faktor von knapp 1000 an Performance gewinnen. (100000 -> 17 * 7)

                                  Weißt Du was Google für eine Datenbank verwendet, oder keine Datenbank?

                                  Es gibt direkt bei Google auch Artikel über deren Technologie.

                                  Viele Grüße
                                        Michael

                                  1. Hi!

                                    +1. Stell' doch mal 'nen Feature-Request ...

                                    wo?
                                    Hab gerade nochmal bei cforum.teamone.de geguckt, da finde ich keinen Hinweis dazu. Dafür aber _sehr_ interessante Featurs vor allem bzgl. des Archivs! Bin schon sehr gespannt, hört sich sehr gut an, soweit man das an den Bezeichnungen sehen kann ;-)

                                    Ich sehe die Benutzung der Suche genauso wie die Benutzung der FAQ: Jeder sollte sie benutzen, nur wenige werden es tatsächlich tun.

                                    Das glaube ich nicht. Wenn die Suche in der Vergangenheit mal nicht ging, da wunderte man sich(ich mich) wer sich darüber alles beschwert hat!

                                    Und auf die tatsächlichen Anwender möchte ich die Funktionalität ausgelegt sehen.

                                    Das finde ich richtig. Ich kann eigentlich auch nur von mir sprechen, es hat schon seine Zeit gedauert bis ich den Selfrauum so einigermaßen überblicken konnte, und selbst heute bin ich immer noch überrascht was es noch so alles gibt.

                                    Wer von sich aus auf die Idee kommt, etwas zu suchen, der sollte _dort_ den Hinweis bekommen, daß es die Tips & Tricks gibt.

                                    Ja, aber das problem sehe ich ein bisschen darin, das man das nicht unbedingt erwartet und mehr oder weniger überliest, oder es nicht wirklich auszunutzen weiß.

                                    Es reicht, wenn man die Augen offen hat, während man im Formular seine Kreuzchen setzt.

                                    Da habe ich erst nach Monaten angefangen was zu verändern...

                                    Vermutlich könnt Ihr es euch nicht erlauben so einen großen Index im RAM zu halten, oder?

                                    Keine Ahnung. Deshalb finde ich Deine Experimente mit mySQL ja so wertvoll. Denn das Prinzip ist ja problemlos auch ohne FULLTEXT verwendbar: Stell Dir einfach vor, Du hättest eine zusätzliche Tabelle mit der Abbildung von Wort auf Posting-ID und würdest über die Worte einen non-unique Index legen ... ich verwendet eine solche Implementierung, und ich habe etwa 20 Millionen Einträge in dieser Tabelle.

                                    Sowas ähnliches habe ich zwischenzeitlich auch gehabt, halt für den Such-String-Sortierer, habe das aber nur kurz versucht, wäre da nicht eine Struktur wie folgt optimal:

                                    Tabelle worte:
                                      wort_ID
                                      wort_STRING

                                    Tabelle postings
                                      wort_ID
                                      posting_ID

                                    dann könnte man über die wort_ID(INT) joinen, über wort_ID in  Tabelle "worte" einen primary_key und über die wort_STRINGs einen normalen Index, genau so wie über beide Spalten der 2. Tabelle, sollte das nicht schneller sein als eine Tabelle?
                                    Aber ich habe ja schon oben mal nachgefragt wegen eines Binärbaums, habe da auch einiges zu gelesen, wie sich das z.B. in PERL abbilden ließe, aber da weiß ich nicht ob das ganz so schlau ist, denn man müßte jedesmal alle Suchworte in einen Hash laden, und jedesmal den Baum mit den Knoten erstellen. Das wird doch tierisch lange dauern. Kann man eine Baumstruktur nicht fest in irgendeiner Datei speichen, das nur noch der fertige Baum geladen werden und durchsucht werden muß, denn das erstellen des Baums wird vermutlich ähnlich lang dauern wie das erstellen des Fulltext-Index!

                                    Es muß nicht alles im RAM liegen.

                                    Aber _das_ macht den entscheidenen Unterschied! Zumindest in meine Tests, wenn der Index im Cache liegt(die SQL-Abfrage kann in MySQL 3.23 noch gar nicht gecached werden!) wird das sehr schnell, sobald der komplette Index auch der Festplatte nach unschärferen Wörtern durchsucht wird wird er langsam.

                                    Es reicht, wenn pro Zugriff nur eine kleine Menge an Seiten ins RAM eingelagert werden müssen. Und Baumstrukturen sind ein Mittel, dies zu erreichen: Wenn die Komplexität bei 100000 Postings von linear auf logarithmisch sinkt, kannst Du einen Faktor von knapp 1000 an Performance gewinnen. (100000 -> 17 * 7)

                                    bisher konnte ich davon herzlich wenig spüren. viel schneller als die bestehend Archivsuche wurde ich nicht, eher langsamer, es ist irgendwie ein Trade-Off, am Anfang war alles auf den Cache optimiert, hinterher wollte ich gerade neue Anfragen beschleunigen, dadurch wurden aber die "alten" erheblich langsamer :-(

                                    Viele Grüße
                                    Andreas

                                    1. Hi Andreas,

                                      Vermutlich könnt Ihr es euch nicht erlauben so einen großen Index im RAM zu halten, oder?
                                      Keine Ahnung. Deshalb finde ich Deine Experimente mit mySQL ja so wertvoll. Denn das Prinzip ist ja problemlos auch ohne FULLTEXT verwendbar: Stell Dir einfach vor, Du hättest eine zusätzliche Tabelle mit der Abbildung von Wort auf Posting-ID und würdest über die Worte einen non-unique Index legen ... ich verwendet eine solche Implementierung, und ich habe etwa 20 Millionen Einträge in dieser Tabelle.
                                      Sowas ähnliches habe ich zwischenzeitlich auch gehabt, halt für den Such-String-Sortierer, habe das aber nur kurz versucht, wäre da nicht eine Struktur wie folgt optimal:

                                      Tabelle worte:
                                        wort_ID
                                        wort_STRING

                                      Tabelle postings
                                        wort_ID
                                        posting_ID

                                      schreib mal die Art der Relation dazu (1:1? 1:n? m:n?), dann versteht man es besser.

                                      dann könnte man über die wort_ID(INT) joinen

                                      JOIN kostet Zeit. Muß das sein?

                                      Aber ich habe ja schon oben mal nachgefragt wegen eines Binärbaums, habe da auch einiges zu gelesen, wie sich das z.B. in PERL abbilden ließe, aber da weiß ich nicht ob das ganz so schlau ist, denn man müßte jedesmal alle Suchworte in einen Hash laden, und jedesmal den Baum mit den Knoten erstellen. Das wird doch tierisch lange dauern.

                                      Das finde ich nicht schlimm, wenn anschließend ein daemon diese Struktur sehr lange im Hauptspeicher hält. Genau auf diesem Prinzip basiert das neue Forum ...

                                      Kann man eine Baumstruktur nicht fest in irgendeiner Datei speichen, das nur noch der fertige Baum geladen werden und durchsucht werden muß

                                      Sicher. Das ist dann allerdings extrem änderungsunfreundlich.

                                      denn das erstellen des Baums wird vermutlich ähnlich lang dauern wie das erstellen des Fulltext-Index!

                                      Das kommt darauf an, wie Hashes implementiert sind. Ich habe irgendwas vage in Erinnerung, daß man komplexe Datenstrukturen a la Hash in Perl direkt speichern und wieder laden können soll ... aber von konkreten Programmiersprachen habe ich ja bekanntlich keine Ahnung.

                                      Es muß nicht alles im RAM liegen.
                                      Aber _das_ macht den entscheidenen Unterschied!

                                      Das glaube ich nicht. So viele Zehnerpotenzen schneller als eine gute Festplatte ist der RAM nun auch nicht.

                                      Zumindest in meine Tests, wenn der Index im Cache liegt(die SQL-Abfrage kann in MySQL 3.23 noch gar nicht gecached werden!) wird das sehr schnell, sobald der komplette Index auch der Festplatte nach unschärferen Wörtern durchsucht wird wird er langsam.

                                      Sorry, das ist mir nicht konkret genug. Was heißt "unschärfere Wörter"? Dort kann die Ursache des Problems stecken.

                                      Es reicht, wenn pro Zugriff nur eine kleine Menge an Seiten ins RAM eingelagert werden müssen. Und Baumstrukturen sind ein Mittel, dies zu erreichen: Wenn die Komplexität bei 100000 Postings von linear auf logarithmisch sinkt, kannst Du einen Faktor von knapp 1000 an Performance gewinnen. (100000 -> 17 * 7)
                                      bisher konnte ich davon herzlich wenig spüren. viel schneller als die bestehend Archivsuche wurde ich nicht, eher langsamer

                                      Du bekommst nicht alle Zugriffe schneller. Du bekommt Zugriffe mit wenigen und gut projezierenden Zugriffen sehr viel schneller, während Zugriffe mit vielen und/oder schlecht projezierenden Suchbegriffen bei Dir variabel viel kosten, im Original aber alles gleich viel.

                                      es ist irgendwie ein Trade-Off, am Anfang war alles auf den Cache optimiert, hinterher wollte ich gerade neue Anfragen beschleunigen, dadurch wurden aber die "alten" erheblich langsamer :-(

                                      Deshalb braucht das Ding ja auch eine Aufgabenstellung.
                                      _Ich_ weiß genau, warum ich Deine Implementierung lieber bedienen wollen würde als meine: Weil ich gut projezierende Suchbegriffe kenne. Deine Implementierung ist sehr viel expertenfreundlicher - wer sie richtig bedient, kann damit Quantensprünge erreichen. Meine Implementierung ist für alle Anwender fast gleich langsam ... wobei auch dort die Verwendung von spaltenbezogenen Suchbegriffen etwas bringt, aber keine großen Faktoren.
                                      Und nun überlege Dir, für welche Zielgruppe _Du_ implementieren willst ...

                                      Oder noch krasser: Glaubst Du, aus der Eingabe der Such-Maske (blacklist, Zahl der Suchbegriffe, etc.) schließen zu können, ob der lineare oder der logarithmische Ansatz schneller sein wird? Du könntest ja auch beides implementieren und dynamisch entscheiden, was Du wirklich tust ... jetzt denk Dir noch ein bißchen KI dazu, also eine lernfähige Maschine ...

                                      Viele Grüße
                                            Michael

                                      1. Hallo!

                                        Tabelle worte:
                                          wort_ID
                                          wort_STRING

                                        Tabelle postings
                                          wort_ID
                                          posting_ID

                                        schreib mal die Art der Relation dazu (1:1? 1:n? m:n?), dann versteht man es besser.

                                        damit hab ichs nicht so, bin halt leider kein Relationaler DB-Experte ;-)
                                        Aber ich versuchs trotzdem mal:

                                        Tabelle worte:          Tabelle wort_in_postings:      Tabelle postings
                                         +--+ ID(primary)         +------+ wort_ID         +------+ ID(primary)
                                         |  + wort_STRING         |   +--+ posting_ID      |      + Titel
                                         |                        |   |                    |      + Autor
                                         |                        |   +--------------------+      + Timestamp
                                         +------------------------+            n:1                + ...
                                                   1:n

                                        JOIN kostet Zeit. Muß das sein?

                                        So wäre es jedenfalls erstmal schön relational, aber mir ist bewußt das schön nicht unbedingt = schnell bedeuten muß. Auf der anderen Seite muß man überlegen das durch weniger Daten die einzelnen Anfragen schneller sind, als wen viele unnötige Daten die "Leitungen und den RAM verstopfen".

                                        Das finde ich nicht schlimm, wenn anschließend ein daemon diese Struktur sehr lange im Hauptspeicher hält. Genau auf diesem Prinzip basiert das neue Forum ...

                                        Das wäre aber dasselbe als wolle ich den kompletten MySQL Fulltext-Index im RAM halten, und das war schon etwas viel!

                                        Kann man eine Baumstruktur nicht fest in irgendeiner Datei speichen, das nur noch der fertige Baum geladen werden und durchsucht werden muß

                                        Sicher. Das ist dann allerdings extrem änderungsunfreundlich.

                                        denn das erstellen des Baums wird vermutlich ähnlich lang dauern wie das erstellen des Fulltext-Index!

                                        Das kommt darauf an, wie Hashes implementiert sind. Ich habe irgendwas vage in Erinnerung, daß man komplexe Datenstrukturen a la Hash in Perl direkt speichern und wieder laden können soll ... aber von konkreten Programmiersprachen habe ich ja bekanntlich keine Ahnung.

                                        Es muß nicht alles im RAM liegen.
                                        Aber _das_ macht den entscheidenen Unterschied!

                                        Das glaube ich nicht. So viele Zehnerpotenzen schneller als eine gute Festplatte ist der RAM nun auch nicht.

                                        Es würde ja eine 10er Potenz reichen die Wartezeit von 5 auf 0,5 Sekunden zu senken, das würde mir ja schon reichen!

                                        Zumindest in meine Tests, wenn der Index im Cache liegt(die SQL-Abfrage kann in MySQL 3.23 noch gar nicht gecached werden!) wird das sehr schnell, sobald der komplette Index auch der Festplatte nach unschärferen Wörtern durchsucht wird wird er langsam.

                                        Sorry, das ist mir nicht konkret genug. Was heißt "unschärfere Wörter"? Dort kann die Ursache des Problems stecken.

                                        Sorry, faslch ausgedrückt, ich meien so allgemeine, oft vorkommende Begriffe wie HTML oder Javascript(übrigens das hier am meisten vorkommende mit dem allgemeinen Thema Webdesign zusammenhängende Wort)

                                        Es reicht, wenn pro Zugriff nur eine kleine Menge an Seiten ins RAM eingelagert werden müssen. Und Baumstrukturen sind ein Mittel, dies zu erreichen: Wenn die Komplexität bei 100000 Postings von linear auf logarithmisch sinkt, kannst Du einen Faktor von knapp 1000 an Performance gewinnen. (100000 -> 17 * 7)
                                        bisher konnte ich davon herzlich wenig spüren. viel schneller als die bestehend Archivsuche wurde ich nicht, eher langsamer

                                        Du bekommst nicht alle Zugriffe schneller. Du bekommt Zugriffe mit wenigen und gut projezierenden Zugriffen sehr viel schneller, während Zugriffe mit vielen und/oder schlecht projezierenden Suchbegriffen bei Dir variabel viel kosten, im Original aber alles gleich viel.

                                        Ja, aber Zeiten wie 5 Sekunden kann ich einfach nicht tolerieren finde ich! Darauf habe ich es bis jetzt senken können z.B., bei "javascript opener", Da brauchst Du nichtmal 1 Sekunde für.

                                        Deshalb braucht das Ding ja auch eine Aufgabenstellung.
                                        _Ich_ weiß genau, warum ich Deine Implementierung lieber bedienen wollen würde als meine: Weil ich gut projezierende Suchbegriffe kenne. Deine Implementierung ist sehr viel expertenfreundlicher - wer sie richtig bedient, kann damit Quantensprünge erreichen.

                                        Naja, davon sehe ich nmich noch weit entfernt, ich erlebe zwar Quantensprünge, eber eher von "unhaltbar lahmarschig" nach nur noch "nervig langsam" ;-)

                                        Meine Implementierung ist für alle Anwender fast gleich langsam ... wobei auch dort die Verwendung von spaltenbezogenen Suchbegriffen etwas bringt, aber keine großen Faktoren.
                                        Und nun überlege Dir, für welche Zielgruppe _Du_ implementieren willst ...

                                        Oder noch krasser: Glaubst Du, aus der Eingabe der Such-Maske (blacklist, Zahl der Suchbegriffe, etc.) schließen zu können, ob der lineare oder der logarithmische Ansatz schneller sein wird? Du könntest ja auch beides implementieren und dynamisch entscheiden, was Du wirklich tust ... jetzt denk Dir noch ein bißchen KI dazu, also eine lernfähige Maschine ...

                                        Als erstes würde ich das Menbü schonmal anbders aufbauen als das bestehende, kannes zwar leide rnicht zeigen, aber mal grob:

                                        [ENGABE SUCHBEGRIFF(E)]
                                        [SELECFELD: Kategorie( wie im Forum)]
                                        [EINGABEFELD: Autor]
                                        [OPTIONSFELD: Auflistung chronoligisch/ranking]
                                        [CHECKBOX: alle Suchbegriffe müssen enthalten sein (ist nämlich eh in 90% der Fälle gewünscht)]

                                        Durch das vorherige Sortieren der Suchbegriffe kann ich das schonmal erheblich besser in meine Suche einbauen. Dann prüfe ich die Worte im Suchstring auf Vorkommen, das seltenere wird dann zuerst in die SQL-Query geschrieben. Naja, und da könnte ich jetzt auch ansetzen und hier verschiedene Suchpfade erstellen usw.

                                        Wie ist das eigentlich bei PostGreSQL, gibt es da ein Äquivalent zum MySQL Fulltext-Index, oder bräuchte man hier die Version mit den/der eigenen Tabelle?

                                        Viele Grüße
                                        Andreas

                                        1. Hi Andreas,

                                          schreib mal die Art der Relation dazu (1:1? 1:n? m:n?), dann versteht man es besser.
                                          damit hab ichs nicht so, bin halt leider kein Relationaler DB-Experte ;-)
                                          Aber ich versuchs trotzdem mal:

                                          Tabelle worte:          Tabelle wort_in_postings:      Tabelle postings
                                          +--+ ID(primary)         +------+ wort_ID         +------+ ID(primary)
                                          |  + wort_STRING         |   +--+ posting_ID      |      + Titel
                                          |                        |   |                    |      + Autor
                                          |                        |   +--------------------+      + Timestamp
                                          +------------------------+            n:1                + ...
                                                     1:n

                                          ups - in Verdana kann ich davon nichts lesen.

                                          Innerhalb der Textarea dann schon: Ah, ja.
                                          Die Tabelle wort_in_postings ist diejenige, welche von FULLTEXT quasi implizit erzeugt wird.
                                          Dann weiß ich allerdings nicht, warum Du zwischen wort_ID und wort_STRING noch einen JOIN machen willst, wo Du doch auch beide Tabellen über die ID verschmelzen kannst. Die ID muß in _dieser_ Tabelle nicht unique sein - sie muß nur einen unique-Zugriff in postings erlauben.

                                          Das finde ich nicht schlimm, wenn anschließend ein daemon diese Struktur sehr lange im Hauptspeicher hält. Genau auf diesem Prinzip basiert das neue Forum ...
                                          Das wäre aber dasselbe als wolle ich den kompletten MySQL Fulltext-Index im RAM halten, und das war schon etwas viel!

                                          Genau. Und FULLTEXT würde von der Datenbank sogar noch seitenweise ein- und ausgelagert ... das macht Perl mit seinem Hash vielleicht auch, aber ich fürchte, Du mußt die Daten bei der Perl-Lösung wenigstens einmal komplett "durch den Speicher schießen", bevor sie in der paging area landen.

                                          Es muß nicht alles im RAM liegen.
                                          Aber _das_ macht den entscheidenen Unterschied!
                                          Das glaube ich nicht. So viele Zehnerpotenzen schneller als eine gute Festplatte ist der RAM nun auch nicht.
                                          Es würde ja eine 10er Potenz reichen die Wartezeit von 5 auf 0,5 Sekunden zu senken, das würde mir ja schon reichen!

                                          Wenn Du den Faktor 10 zwischen RAM und Platte damit bezahlst, den kompletten Index und damit tausendmal so viel wie notwendig einlesen zu müssen, dann hast Du nichts gewonnen.

                                          Sorry, das ist mir nicht konkret genug. Was heißt "unschärfere Wörter"? Dort kann die Ursache des Problems stecken.
                                          Sorry, falsch ausgedrückt, ich meine so allgemeine, oft vorkommende Begriffe wie HTML oder Javascript (übrigens das hier am meisten vorkommende mit dem allgemeinen Thema Webdesign zusammenhängende Wort)

                                          Genau. Und die sind so unscharf, daß sie auf die schwarze Liste gehören.

                                          Es reicht, wenn pro Zugriff nur eine kleine Menge an Seiten ins RAM eingelagert werden müssen. Und Baumstrukturen sind ein Mittel, dies zu erreichen: Wenn die Komplexität bei 100000 Postings von linear auf logarithmisch sinkt, kannst Du einen Faktor von knapp 1000 an Performance gewinnen. (100000 -> 17 * 7)
                                          bisher konnte ich davon herzlich wenig spüren. viel schneller als die bestehend Archivsuche wurde ich nicht, eher langsamer

                                          Bei guten Suchbegriffen bist Du deutlich schneller geworden, dachte ich? Oder sind es immer erst mal 5 Sekunden, egal was Du suchst?

                                          Ja, aber Zeiten wie 5 Sekunden kann ich einfach nicht tolerieren finde ich! Darauf habe ich es bis jetzt senken können z.B., bei "javascript opener", Da brauchst Du nichtmal 1 Sekunde für.

                                          Bei dieser Anforderung ist "opener" der 'gute' Suchbegriff, der die Sache schnell macht. Und da er nicht auf der schwarzen Liste steht, im Gegensatz zu "javascript", weißt Du auch, wie Du diese beiden Begriffe zu sortieren hast ...

                                          Als erstes würde ich das Menbü schonmal anbders aufbauen als das bestehende, kannes zwar leide rnicht zeigen, aber mal grob:
                                          [ENGABE SUCHBEGRIFF(E)]
                                          [SELECFELD: Kategorie( wie im Forum)]
                                          [EINGABEFELD: Autor]
                                          [OPTIONSFELD: Auflistung chronoligisch/ranking]
                                          [CHECKBOX: alle Suchbegriffe müssen enthalten sein (ist nämlich eh in 90% der Fälle gewünscht)]

                                          Du bist Dir bewußt, daß dies (über eine entsprechende Notation im Eingabefeld) alles bereits mit der bestehenden Suchfunktion möglich ist? (Ausgenommen die Checkbox - die ist bisher auf "aktiv" festgebrannt.)

                                          Durch das vorherige Sortieren der Suchbegriffe kann ich das schonmal erheblich besser in meine Suche einbauen.

                                          Bist Du Dir bewußt, daß Du dann mehr als einen FULLTEXT-Index verwenden wollen wirst?

                                          Dann prüfe ich die Worte im Suchstring auf Vorkommen, das seltenere wird dann zuerst in die SQL-Query geschrieben.

                                          Wenn Du mit derartig komplexen Möglichkeiten anfängst, dann wird die Sache mit der Generierung einer guten Query sehr viel anspruchsvoller. Denn eine Blacklist für Suchbegriffe hat eine ganz andere Wirkung als eine Blacklist für Autoren etc.

                                          Viele Grüße
                                                Michael

                                          --
                                          T'Pol: I meant no insult.
                                          V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                          1. Hallo Michael!

                                            ups - in Verdana kann ich davon nichts lesen.

                                            ah ja, eigene CSS...

                                            Innerhalb der Textarea dann schon: Ah, ja.
                                            Die Tabelle wort_in_postings ist diejenige, welche von FULLTEXT quasi implizit erzeugt wird.

                                            Was ich jetz imme rnoch nicht genau verstanden habe - erstellt FULLTEXT jetzt eine interne Tabelle wie oben, oder einen B-Baum? SO wie ich das jetzt verstanden habe wohl ersteres, aber wo ist das noch logarithmisch?

                                            Dann weiß ich allerdings nicht, warum Du zwischen wort_ID und wort_STRING noch einen JOIN machen willst, wo Du doch auch beide Tabellen über die ID verschmelzen kannst. Die ID muß in _dieser_ Tabelle nicht unique sein - sie muß nur einen unique-Zugriff in postings erlauben.

                                            Ja, dann hat man das ganze halt nicht mehr so "schön relational", aber der JOIN ist vermutlich teurer als der zusätzlich erzeugte IO-Traffic durch "unnötige" mehrfache Speicherung, oder?

                                            Genau. Und FULLTEXT würde von der Datenbank sogar noch seitenweise ein- und ausgelagert ...

                                            Was meinst Du mit "seitenweise"?

                                            das macht Perl mit seinem Hash vielleicht auch, aber ich fürchte, Du mußt die Daten bei der Perl-Lösung wenigstens einmal komplett "durch den Speicher schießen", bevor sie in der paging area landen.

                                            "paging area"? Was ist das?

                                            Wenn Du den Faktor 10 zwischen RAM und Platte damit bezahlst, den kompletten Index und damit tausendmal so viel wie notwendig einlesen zu müssen, dann hast Du nichts gewonnen.

                                            Ist doch dasselbe wie bei dem unnötigen Join, ich werde schneller und bezahle das mit mehr Speicher, scheint öfter so zu sein. Die Frage ist nur ob man ein System was immer komplett auf die Festplatte zugreifen muß so schnell bekommt? Denn wie schnell ist nochmal eine IDE Leitung? War glaube ich praktisch nicht mehr als 50MB/sekunde, und wie macht das die Datenbank? Die mußt doch erstmal die _komplette_ Tabellendatei, oder besser gesagt die Fulltext_index Datei von der Festplatte holen, mit allem drum und dran(alte Archive...) sind das gut und gerne 250 MB, was also schonmal 5 Sekunden dauert, wenn man die komplette Bandbreite 5 Sekunden für eine einzige Suchanfrage zur Verfügung hat. Der Rest geht dann echt flott, aber gerade das ist glaube ich das Problem bei mir! Und bei meinem 133er DDR SDRAM ist die Rate immerhin bei 2,1 GB/sekunde, zumindest theoretisch, aber das wäre schonmal der Faktor 40, also deutlich mehr als 1 Zehnerpotenz!
                                            Gut, bei mir sind es nur 110 MB die der Index groß ist, also dürfte ich noch andere Probleme haben, und Ihr habt doch SCSI, und RAID (welches?), wordurch ihr ja doch an erheblich höherer Raten gelangen könntet, aber wie gesagt, die Suche ist ja nicht alles was auf dem Server läuft! Da sehe ich auch den Vorteil in der Verzeichnisbaum-Version, da muß nicht  viel von der Festplatte geholt werden, das Sortieren geschieht einfach mit dem Verzeichnisbaum, also logarithmisch und nicht linear => 2 Vorteile in einem.
                                            Aber mit hinzufügen von Informationen könnte wirklich kritisch werden, wobei, das würde sowieso ein Script erledigen und ich wüßte jetzt nicht wo das Problem liegen sollte, naja, aber das eine Datenbank da einfacher sein wird glaube ich sehr wohl.

                                            Genau. Und die sind so unscharf, daß sie auf die schwarze Liste gehören.

                                            Ja! Hab ich ja, aber das bringt sooo viel auch nicht! Das Wort kommt nunmal vor und muß dem entsprechend auch gesucht werden.

                                            Bei guten Suchbegriffen bist Du deutlich schneller geworden, dachte ich? Oder sind es immer erst mal 5 Sekunden, egal was Du suchst?

                                            Ich bin bei seltenen eher langsamer(bei wiederholter(ge-cachter) Suche) geworden, das war früher sauschnell, aber durch das vorsortieren der Begriffe... geht natürlich Zeit verloren, aber das macht eigentlich nicht viel, bei schlechten Suchbegriffen habe ich mich deutlich verbessert, von sagen wie mal 20 Sekunden am Anfang, auf 5 Sekunden, halt wegen der Sorterung. Genau wie bei seltenen BEgriffen, da bin ich jetzt auch schon bei der ersten Suchanfrage akzeptabel schnell(1-2 Sekunden). Aber sobald ein Wort wie Javascript in der Query vorkommt, bin ich bei den blöden 5 Sekunden, und beim 4. mal immer noch über 1 Sekunde. Bei 1 oder 2 seltenen Wörtern bin ich wie gesagt sofort ziemlich schnell, ca. 1 Sekunde und danach noch schneller. Aber Deine Suche ist meiner durch die Modifikationen in _allen_ Belangen überlegen(schneller), früher war ich wenigstens wenn ich Anfragen im Cache hatte recht flott, das bin ich jetzt nicht mehr(in dem Maße, dafür halt beim 1. mal verbessert). ich guck mal ob ich das ganze gleich mal auf einen echten Webserver hochladen kann, dann kannst Du Dir selbst ein Bild machen. Das Problem ist da nur, dass ich vermutlich keinen Thread so lange laufen lassen kann, bis der Fulltext-Index fertig ist, mal schaun.

                                            Bei dieser Anforderung ist "opener" der 'gute' Suchbegriff, der die Sache schnell macht. Und da er nicht auf der schwarzen Liste steht, im Gegensatz zu "javascript", weißt Du auch, wie Du diese beiden Begriffe zu sortieren hast ...

                                            Das mach ich ja, dadruch hat sich die Geschwindigkeit von 20 auf 5 Sekunden verbessert! Aber irgendwas mache ich da wohl noch ganz grob falsch! So sieht meine Suche aus:
                                            1. Sortierung der Suchbegriffe
                                            2. generiere Query: "CREATE TEMPORARY TABLE...SELECT...FROM postings WHERE MATCH(...) AGAINST('opener') AND MATCH(...) AGAINST('javascript')"
                                            3. Frage temp-Tabelle ab: "SELECT ... FROM temporäre_tabelle... ORDER BY time"

                                            Schritt 2 ist das Problem, der braucht 99% der Zeit. Nur Suchen gegen  _ganz_ seltene Begriffe sind schnell, aber diese Suchen sind auch sehr selten, und vermutlich gar nicht mehr so schnell wenn gleichzeitig 10 Leute nach Javascript, HTML & Co. suchen.

                                            Du bist Dir bewußt, daß dies (über eine entsprechende Notation im Eingabefeld) alles bereits mit der bestehenden Suchfunktion möglich ist? (Ausgenommen die Checkbox - die ist bisher auf "aktiv" festgebrannt.)

                                            Sehr bewußt sogar, ich benutze das auch öfter, vor allem author:"Andreas Korthaus". Was aber nicht funktioniert ist category:"ZU DIESEM FORUM", das geht nicht. Und außerdem:
                                            Wie oft benutzt das jemand: http://webalizer.teamone.de/selfforum/search_200211.htm?
                                            Ich denke so ein Forumlar mit den direkten Eingabe-Möglichkeiten würden mehr Leute benutzen, vor allem "Anfänger", und damit allen anderen den Gefallen tun die Suche erheblich zu entlasten.
                                            Ist auch entspannter mal eben aus einem SelectFeld die KAtegorie auszuwählen, als das komplett als category:"ZU DIESEM FORUM" auszuschreiben. Da bin ich faul ;-)

                                            Durch das vorherige Sortieren der Suchbegriffe kann ich das schonmal erheblich besser in meine Suche einbauen.

                                            Bist Du Dir bewußt, daß Du dann mehr als einen FULLTEXT-Index verwenden wollen wirst?

                                            Nein. Wieso? Ich kann eh nur einen Index verwenden und da _muss_ ich den Fulltext über alle Spalten nehmen. Wozu braucheich einen Volltext-Index bei Kategorie? Da habe ich ja feste Strings die ich vergleiche kann. Ich könnte sogar die Strings in Zahlen umfandeln, halt für jede Kategorie eine Zahl das dürfte nochmal helfen! Bei den Namen ist es egal, wenn ich da instr() verwende, wird die Query kein Stück langsamer. Und Wenn jetz jemand _nur_ seine letzten Postuings sucht, dann könnte man das bestimmt optimieren, aber darum geht es mir vorerst nicht. mit geht es um Eingaben wie :

                                            Suchstring: fsockopen
                                            Autor: Andreas

                                            dann mache ich wieder einen match gegen fsockopen, und danach ein AND instr(author,"Andreas"). DAs geht IMHO sehr gut, auch wenn nicht verstehe wieso. Aber was soll ich sonst machen? Einen Index kann ich eh vergessen, denn fsockopen braucht nunmal unbedingt den Fulltext-Index. Dann muß ich gucken wie ich noch den Namen filtere, "Andreas" ist natürlich kein selten vorkommender Name, aber was will man machen? Denn anders herum, erst alle Postings von "Andreas" mit einem Fulltext über die Spalte Author abzufragen udn dann mit Like oder instr() den Rest, das ist doch vermutlich _erheblich_ schlechter, oder? Wieviele Andreas-Postings gibt es? Sind alleine von mir über 2000 und ich bin nicht der einzige Andreas. Ich denke man sollte das mit dem Fulltext index sein lassen und mal mit einer eigenen Tabelle wie ganz oben geschreiben probieren, da hat man mehr Freiheit und zumindest ich versteh das ganze dann besser, der Fulltext Index ist doch noch irgendwie ein Mysterium für mich, obwohl ich das Kapitel schon mehrfach gelesen habe, ist leider nicht sonderlich lang, und ausführlich, aber wenn das ganze logarithmisch funktionieren würde(was es IMHO nicht tut), dann müßte ich doch wenigstens so Werte wie Deine lineare PERL Suche erreichen, bei so vielen Datensätzen. Ich weiß es nicht aber die Volltext-Suche kann ich irgendwie nicht richtig fassen, ich habe so wenig Einfluß darauf, oder zumindest kann ich meinen Einfluß nicht ausnutzen. Vielleicht hat es auch mit meiner erheblich langsameren "Festplattenanbindung" zu tun, aber auch dann ist der Unterschied immer noch zu groß.

                                            Wenn Du mit derartig komplexen Möglichkeiten anfängst, dann wird die Sache mit der Generierung einer guten Query sehr viel anspruchsvoller. Denn eine Blacklist für Suchbegriffe hat eine ganz andere Wirkung als eine Blacklist für Autoren etc.

                                            Ja, die Query wird deutlich schneller, ist aber immer noch viel zu langsam ;-)
                                            Bisher ging das mit den Datenbanken immer ganz gut, da habe ich mir nie Gedanken über eine Query gemacht, aber das hier ist schon verrückt denn so viele Gedanken wie ich mir gemacht habe(mit Deiner Hilfe), und trotzdem ist noch nicht so viel bei rumgekommen.

                                            Viele Grüße
                                            Andreas

                                            1. Hallo Andreas,

                                              Innerhalb der Textarea dann schon: Ah, ja.
                                              Die Tabelle wort_in_postings ist diejenige, welche von
                                              FULLTEXT quasi implizit erzeugt wird.
                                              Was ich jetz imme rnoch nicht genau verstanden habe -
                                              erstellt FULLTEXT jetzt eine interne Tabelle wie oben,
                                              oder einen B-Baum?

                                              Wo ist der Unterschied? Und ist das wichtig?

                                              SO wie ich das jetzt verstanden habe wohl ersteres, aber
                                              wo ist das noch logarithmisch?

                                              Die Zugriffspfade muessen nicht zwingenderweise sequentiell
                                              sein. Durch passend gelegte Indizes kann man statt eines
                                              sequentiellen Algorithmus einen (fast) logarithmischen
                                              Algorithmus benutzen.

                                              Genau. Und FULLTEXT würde von der Datenbank sogar noch
                                              seitenweise ein- und ausgelagert ...
                                              Was meinst Du mit "seitenweise"?

                                              Das heisst, dass *nicht* der komplette Index im Speicher
                                              gehalten wird, sondern nur teilweise im Speicher behalten
                                              werden braucht.

                                              das macht Perl mit seinem Hash vielleicht auch, aber
                                              ich fürchte,

                                              Nein, Perl haelt alle Hashes komplett im Speicher. Wenn etwas
                                              auf die HD ausgelagert wird, dann wird das vom OS gemacht
                                              (Swapping), aber nicht von Perl.

                                              Du mußt die Daten bei der Perl-Lösung
                                              wenigstens einmal komplett "durch den Speicher
                                              schießen", bevor sie in der paging area landen.

                                              Was meinst du mit dem oberen Satz, Michael?

                                              Denn wie schnell ist nochmal eine IDE Leitung?

                                              Kommt darauf an, welcher IDE-Standard. UDMA133 kann bis zu
                                              133MB/s transferieren.

                                              und wie macht das die Datenbank? Die mußt doch erstmal die
                                              _komplette_ Tabellendatei, oder besser gesagt die
                                              Fulltext_index Datei von der Festplatte holen,

                                              Warum sollte sie? Dateien sind nicht sequentiell. Man darf
                                              durchaus auch nur 10 Byte in der Mitte auslesen, oder 100
                                              Byte am Anfang.

                                              Durch das vorherige Sortieren der Suchbegriffe kann ich das schonmal erheblich besser in meine Suche einbauen.

                                              Wozu braucheich einen Volltext-Index bei Kategorie? Da
                                              habe ich ja feste Strings die ich vergleiche kann. Ich
                                              könnte sogar die Strings in Zahlen umfandeln, halt für
                                              jede Kategorie eine Zahl das dürfte nochmal helfen!

                                              Unwahrscheinlich. Wenn, dann nicht merkbar. String-Indizes
                                              sind im Normalfall Hashing-Indizes, und die sind nicht
                                              wirklich langsamer als Zahlen-Indizes.

                                              Gruesse,
                                               CK

                                              1. Hallo Christian!

                                                Was ich jetz imme rnoch nicht genau verstanden habe -
                                                erstellt FULLTEXT jetzt eine interne Tabelle wie oben,
                                                oder einen B-Baum?

                                                Wo ist der Unterschied?

                                                Ich dachte immer ein Binärer Baum würde bei einem Wort anfangen und sich dann weiter verzweigen, wie man das ganze "statisch" speichern soll ist dann so eien Sache die ich noch nicht wirklich verstanden  habe, aber das soll wohl gehen. Eine Tabelle wird ja nur linear durchsucht. Aber ich verstehe inzwsichen doch den Vorteil, denn die Tabelle enthält zwar alle Wärter der indizierten Spalte(n), aber jedes nur einmal. Somit spart man durchaus Zeit. Nur braucht manb dann ncoh die Information, in welchem Datensatz das besagte Wort jetzt vorkommt, udn hierzu braucht man IMHO eine 2. Tabelle in der der eine Verknüpfung zw. Wort und Posting_IDhergestellt, wird. Wenn man nur eine  einzige TAbelle verwenden würde, dann müßte man in die eine Tabelle genausoviele Datensät7ze schreiben wie die zu indizierende Spalte Wörter enthält, und nicht jedes einmal, sondern so oft es insgesamt vorkommt, mit einer 2. Spalte Posting_ID. Oder war es das was Michael meinte, dann halt mit einem non_unique Index über die Wort-Spalte?

                                                Und ist das wichtig?

                                                Dachte ich...

                                                Das heisst, dass *nicht* der komplette Index im Speicher
                                                gehalten wird, sondern nur teilweise im Speicher behalten
                                                werden braucht.

                                                aber welcher Teil? Woher weiß ich vorher was der User als nächstes in der DB sucht?

                                                Denn wie schnell ist nochmal eine IDE Leitung?

                                                Kommt darauf an, welcher IDE-Standard. UDMA133 kann bis zu
                                                133MB/s transferieren.

                                                Theoretisch, praktisch aber nur die von mir genannten gut 50 MB/sek.

                                                Warum sollte sie? Dateien sind nicht sequentiell. Man darf
                                                durchaus auch nur 10 Byte in der Mitte auslesen, oder 100
                                                Byte am Anfang.

                                                OK, aber woher weiß ich jetzt welche 10 Byte ich genau raushole? Wenn ich den Index nicht im Speicher habe, muß ich doch bei einer Anfrage erstmal den kompletten Index in den Speicher laden, um dann mit Hilfe des Index(denn ich einmal komplett parsen muß) den Teil der Tabellendatei zu ermitteln, den ich jetzt gut gebrauchen könnte, oder? Das Problem ist nur das der Index selbst zu groß ist für den RAM! Zumindest wenn gleichzeitig noch andere Software laufen soll.

                                                Wozu braucheich einen Volltext-Index bei Kategorie? Da
                                                habe ich ja feste Strings die ich vergleiche kann. Ich
                                                könnte sogar die Strings in Zahlen umfandeln, halt für
                                                jede Kategorie eine Zahl das dürfte nochmal helfen!

                                                Unwahrscheinlich. Wenn, dann nicht merkbar. String-Indizes
                                                sind im Normalfall Hashing-Indizes, und die sind nicht
                                                wirklich langsamer als Zahlen-Indizes.

                                                Ja? Das hat mir jemand mal ganz anders erklärt, dass ein String-Vergleich vor allem in größeren Tabellen erheblich länger dauert als ein Integer-Vergleich. Aber wenn Du das sagst - gut zu wissen! Wobei da auf alle Fälle das Argument zieht, das mit der Verwendung von INT Werten an Stelle von mehr oder weniger langen Strings auf alle Fälle weniger Speicher, RAM und Bandbreit verbraucht wird, was die ganze Anwendung mehr oder weniger beschleunigen sollte, steht so oder so ähnlich im MYSQL Manual im Kapitel Server-Optimierung.

                                                Viele Grüße
                                                Andreas

                                                1. Hallo Andreas,

                                                  Was ich jetz imme rnoch nicht genau verstanden habe -
                                                  erstellt FULLTEXT jetzt eine interne Tabelle wie
                                                  oben, oder einen B-Baum?

                                                  Wo ist der Unterschied?
                                                  Ich dachte immer ein Binärer Baum würde bei einem Wort
                                                  anfangen und sich dann weiter verzweigen, wie man das
                                                  ganze "statisch" speichern soll ist dann so eien Sache die
                                                  ich noch nicht wirklich verstanden  habe, aber das soll
                                                  wohl gehen. Eine Tabelle wird ja nur linear durchsucht.

                                                  Wer sagt das? Eine Tabelle kann auf viele verschiedene Arten
                                                  durchsucht werden, abhaengig von ihren Indizes und den
                                                  gestellten Queries.

                                                  Aber ich verstehe inzwsichen doch den Vorteil, denn die
                                                  Tabelle enthält zwar alle Wärter der indizierten
                                                  Spalte(n), aber jedes nur einmal. Somit spart man durchaus
                                                  Zeit. Nur braucht manb dann ncoh die Information, in
                                                  welchem Datensatz das besagte Wort jetzt vorkommt, udn
                                                  hierzu braucht man IMHO eine 2. Tabelle in der der eine
                                                  Verknüpfung zw. Wort und Posting_IDhergestellt, wird.

                                                  Korrekt. Tatsaechlich ist es sinnvoll, das mit 3 Tabellen zu
                                                  loesen, da eine n:m-Beziehung vorliegt:

                                                  Postings        Woerter
                                                     |     Nodes     |
                                                     |       |       |
                                                     +-------+-------+
                                                       1:n       n:1

                                                  Jedem Posting sind n Nodes zugeordnet, jeder Node ist 1 Wort
                                                  zugeordet.

                                                  Wenn
                                                  man nur eine  einzige TAbelle verwenden würde, dann müßte
                                                  man in die eine Tabelle genausoviele Datensät7ze schreiben
                                                  wie die zu indizierende Spalte Wörter enthält,

                                                  Korrekt.

                                                  und nicht
                                                  jedes einmal, sondern so oft es insgesamt vorkommt, mit
                                                  einer 2. Spalte Posting_ID.

                                                  Warum sollte man Woerter doppelt speichern? Du kannst
                                                  stattdessen die Wertigkeit mitspeichern, in einer weiteren
                                                  Spalte.

                                                  Und ist das wichtig?
                                                  Dachte ich...

                                                  Der Fulltext-Index ist eine Blackbox. Wie genau er
                                                  funktioniert, ist doch eigentlich unwichtig.

                                                  Das heisst, dass *nicht* der komplette Index im Speicher
                                                  gehalten wird, sondern nur teilweise im Speicher
                                                  behalten werden braucht.
                                                  aber welcher Teil?

                                                  Der Teil, der gerade nur benoetigt wird.

                                                  Woher weiß ich vorher was der User als nächstes in der DB
                                                  sucht?

                                                  Gar nicht. Warum solltest du das wissen muessen? Behalte die
                                                  durchschnittlich am meisten gebrauchten Teile permanent im
                                                  Speicher und gut.

                                                  Denn wie schnell ist nochmal eine IDE Leitung?

                                                  Kommt darauf an, welcher IDE-Standard. UDMA133 kann bis
                                                  zu 133MB/s transferieren.
                                                  Theoretisch, praktisch aber nur die von mir genannten gut
                                                  50 MB/sek.

                                                  Und wie kommst du auf solche Aussagen? Kannst du die belegen?

                                                  Warum sollte sie? Dateien sind nicht sequentiell. Man
                                                  darf durchaus auch nur 10 Byte in der Mitte auslesen,
                                                  oder 100 Byte am Anfang.
                                                  OK, aber woher weiß ich jetzt welche 10 Byte ich genau
                                                  raushole?

                                                  Das ergibt sich aus deiner Datei-Struktur.

                                                  Wenn ich den Index nicht im Speicher habe, muß ich doch
                                                  bei einer Anfrage erstmal den kompletten Index in den
                                                  Speicher laden, um dann mit Hilfe des Index(denn ich
                                                  einmal komplett parsen muß) den Teil der Tabellendatei zu
                                                  ermitteln, den ich jetzt gut gebrauchen könnte, oder?

                                                  Warum?
                                                  Nehmen wir mal einen Baumartigen Index. Das Dateiformat kann
                                                  man so anlegen, dass man den Baum direkt anlegen kann. Wenn
                                                  ich jetzt dem Pfad folge, hole ich immer nur genau die Teile
                                                  von der HD, die ich als naechstes brauchen werde. Das kann
                                                  ich z. B. erreichen, indem ich bei jedem Knoten mitspeichere,
                                                  wo die naechste Node zu finden ist. Das kann im einfachsten
                                                  Fall ein Pointer sein und im schlimmsten Fall ein Dateiname
                                                  mit einem Byte-Index.

                                                  Wozu braucheich einen Volltext-Index bei Kategorie?
                                                  Da habe ich ja feste Strings die ich vergleiche
                                                  kann. Ich könnte sogar die Strings in Zahlen
                                                  umfandeln, halt für jede Kategorie eine Zahl das
                                                  dürfte nochmal helfen!

                                                  Unwahrscheinlich. Wenn, dann nicht merkbar.
                                                  String-Indizes sind im Normalfall Hashing-Indizes, und
                                                  die sind nicht wirklich langsamer als Zahlen-Indizes.
                                                  Ja? Das hat mir jemand mal ganz anders erklärt, dass ein
                                                  String-Vergleich vor allem in größeren Tabellen erheblich
                                                  länger dauert als ein Integer-Vergleich.

                                                  Ein Vergleich durchaus, ja. Aber Hashing basiert nicht auf
                                                  Vergleichen. Es wird eine Hash-Summe erstellt, durch die ein
                                                  direkter Lookup in der Tabelle gemacht werden kann. Natuerlich
                                                  kann ein Hashing-Algorithmus bei einer endlich langen
                                                  Schluessellaenge nicht perfekt sein, aber die Zahl der
                                                  Dupletten haelt sich in Grenzen.

                                                  Gruesse,
                                                   CK

                                                  1. Hi Christian!

                                                    Korrekt. Tatsaechlich ist es sinnvoll, das mit 3 Tabellen zu
                                                    loesen, da eine n:m-Beziehung vorliegt:

                                                    Postings        Woerter
                                                       |     Nodes     |
                                                       |       |       |
                                                       +-------+-------+
                                                         1:n       n:1

                                                    Jedem Posting sind n Nodes zugeordnet, jeder Node ist 1 Wort
                                                    zugeordet.

                                                    Ich glaube so habe ich es mir auch vorgestellt.

                                                    und nicht
                                                    jedes einmal, sondern so oft es insgesamt vorkommt, mit
                                                    einer 2. Spalte Posting_ID.

                                                    Warum sollte man Woerter doppelt speichern? Du kannst
                                                    stattdessen die Wertigkeit mitspeichern, in einer weiteren
                                                    Spalte.

                                                    Das hatte ich jetzt Michaels Aussage entnommen, dass man nur eine Tabelle verwendet, mit je Wort => Posting_ID, und dann könnte man über Wort einen Index legen ung hätte dann auch sowas wie eine logarithmische Suche, da im Index ja auch nur jedes Wort 1 mal vorkommt, und mit Hilfe dieses Index kann die DMS dann auf den Teil der Tabellen_Datei zugreifen, der für das Ergebnis relevant ist.

                                                    Der Fulltext-Index ist eine Blackbox. Wie genau er
                                                    funktioniert, ist doch eigentlich unwichtig.

                                                    Naja, ich verstehe halt nicht wieso er so langsam ist/bleibt! Erst durch Caching wird das ganez schnell, nur leider sind die meisten Suchanfragen sehr verschieden und liegen meist nicht mehr im Cache, also wird das ganze extrem langsam. Ich überlege halt eienn Fulltext-Index manuell in einer, bzw. 3 Tabellen nachzubilden. Das würde ich dann wenigstens verstehen und könnte das entsprechend versuchen anzupassen.

                                                    Woher weiß ich vorher was der User als nächstes in der DB
                                                    sucht?

                                                    Gar nicht. Warum solltest du das wissen muessen? Behalte die
                                                    durchschnittlich am meisten gebrauchten Teile permanent im
                                                    Speicher und gut.

                                                    Das ist das was sowohl mein Filesystem als auch der MySQL-Cache tut, nur wenn man sich mal so Suchanfragen ansieht, dann sind die doch sehr verschieden. Das Problem ist das ca. 90% der Suchanfragen sehr selten sind. Die kann an nicht alle im Cache halten, die 10% die öfter sind, gut, aber die nicht gecachten seltenen Anfragen müssen jedesmal im kompleten Index gesucht werden, der Volltext Index für den gesamten Self-Raum hätte bestimmt 250 MB, der müßte dann also komplett einmal geparst werden, durchsucht werden und dann müßten die Daten der Ergebnisse noch aus der Tabellen-Datei von der Platte geholt werden, aber das ist dann das geringste Problem. ODer habe ich das jetzt total faslch verstanden? ODer muß der Index nicht geparst werden?

                                                    Theoretisch, praktisch aber nur die von mir genannten gut
                                                    50 MB/sek.

                                                    Und wie kommst du auf solche Aussagen? Kannst du die belegen?

                                                    Ich habe es in verschiedenen Quellen gelesen, z.B. hier: http://www.de.tomshardware.com/storage/02q1/020301/wd120-01.html, aber auch in der CT..., die Werte sind immer ähnlich.

                                                    OK, aber woher weiß ich jetzt welche 10 Byte ich genau
                                                    raushole?
                                                    Das ergibt sich aus deiner Datei-Struktur.

                                                    was? Welche Dateistruktur? Ich rede hier von einer Datenbank?!

                                                    Nehmen wir mal einen Baumartigen Index. Das Dateiformat kann
                                                    man so anlegen, dass man den Baum direkt anlegen kann. Wenn
                                                    ich jetzt dem Pfad folge, hole ich immer nur genau die Teile
                                                    von der HD, die ich als naechstes brauchen werde. Das kann
                                                    ich z. B. erreichen, indem ich bei jedem Knoten mitspeichere,
                                                    wo die naechste Node zu finden ist. Das kann im einfachsten
                                                    Fall ein Pointer sein und im schlimmsten Fall ein Dateiname
                                                    mit einem Byte-Index.

                                                    Also wird beim MySQL Volltext irgendwie ein binärer Baum auf der Festplatte gespeichert, und der wird dann halt durchsucht(das meine ich mit logarithmisch im Gegensatz zum succesiven Durchsuchen einer Tabelle). Aber das müßte doch tierisch schnell sein, ist es aber nicht. Da muß man wohl noch ein einigen Stellen ausbessern.

                                                    Viele Grüße
                                                    Andreas

                                                    1. Hallo Andreas,

                                                      Warum sollte man Woerter doppelt speichern? Du kannst
                                                      stattdessen die Wertigkeit mitspeichern, in einer
                                                      weiteren Spalte.
                                                      Das hatte ich jetzt Michaels Aussage entnommen, dass man
                                                      nur eine Tabelle verwendet, mit je Wort => Posting_ID, und
                                                      dann könnte man über Wort einen Index legen ung hätte dann
                                                      auch sowas wie eine logarithmische Suche, da im Index ja
                                                      auch nur jedes Wort 1 mal vorkommt,

                                                      Warum sollte in einem Index jedes Wort nur einmal vorkommen?
                                                      Das ist Quark. Natuerlich ist dem *nicht* so.

                                                      Der Fulltext-Index ist eine Blackbox. Wie genau er
                                                      funktioniert, ist doch eigentlich unwichtig.
                                                      Naja, ich verstehe halt nicht wieso er so langsam
                                                      ist/bleibt!

                                                      Du hast wenig Speicher und eine langsame HD. Wenn du den
                                                      Prozess verfolgst (per top oder strace), wirst du
                                                      wahrscheinlich feststellen, dass die meiste Zeit fuer biow
                                                      und bior drauf geht.

                                                      Erst durch Caching wird das ganez schnell,

                                                      Ja, aber nicht das Cachen der Such-Anfragen, sondern das
                                                      Cachen des Indexes.

                                                      Ich überlege halt eienn Fulltext-Index
                                                      manuell in einer, bzw. 3 Tabellen nachzubilden. Das würde
                                                      ich dann wenigstens verstehen und könnte das entsprechend
                                                      versuchen anzupassen.

                                                      Versuchs.
                                                      Wenigsten hast du jetzt gemerkt, dass eine Datenbank *nicht*
                                                      das wunderbare Allheilmittel ist und das eine DB durchaus
                                                      ihre Grenzen hat und nicht fuer alle Einsatzgebiete geeignet
                                                      ist.

                                                      Das ist das was sowohl mein Filesystem als auch der
                                                      MySQL-Cache tut, nur wenn man sich mal so Suchanfragen
                                                      ansieht, dann sind die doch sehr verschieden.

                                                      Du hast nicht genuegend Daten, um wirklich konkrete
                                                      Ergebnisse vorweisen zu koennen.

                                                      Das Problem ist das ca. 90% der Suchanfragen sehr selten
                                                      sind. Die kann an nicht alle im Cache halten, die 10% die
                                                      öfter sind, gut, aber die nicht gecachten seltenen
                                                      Anfragen müssen jedesmal im kompleten Index gesucht
                                                      werden, der Volltext Index für den gesamten Self-Raum
                                                      hätte bestimmt 250 MB, der müßte dann also komplett einmal
                                                      geparst werden, durchsucht werden und dann müßten die
                                                      Daten der Ergebnisse noch aus der Tabellen-Datei von der
                                                      Platte geholt werden, aber das ist dann das geringste
                                                      Problem. ODer habe ich das jetzt total faslch verstanden?
                                                      ODer muß der Index nicht geparst werden?

                                                      Kannst du jetzt das ganze nochmal mit Punkt und Komma fragen?
                                                      Ich habe kein Wort verstanden.

                                                      OK, aber woher weiß ich jetzt welche 10 Byte ich
                                                      genau raushole?
                                                      Das ergibt sich aus deiner Datei-Struktur.
                                                      was? Welche Dateistruktur? Ich rede hier von einer
                                                      Datenbank?!

                                                      Na und? :) Auch eine Datenbank-Datei hat eine Struktur.

                                                      Nehmen wir mal einen Baumartigen Index. Das Dateiformat
                                                      kann man so anlegen, dass man den Baum direkt anlegen
                                                      kann. Wenn ich jetzt dem Pfad folge, hole ich immer nur
                                                      genau die Teile von der HD, die ich als naechstes
                                                      brauchen werde. Das kann ich z. B. erreichen, indem ich
                                                      bei jedem Knoten mitspeichere, wo die naechste Node zu
                                                      finden ist. Das kann im einfachsten Fall ein Pointer
                                                      sein und im schlimmsten Fall ein Dateiname mit einem
                                                      Byte-Index.
                                                      Also wird beim MySQL Volltext irgendwie ein binärer Baum
                                                      auf der Festplatte gespeichert,

                                                      Unwahrscheinlich. Eher ein B-Baum.

                                                      und der wird dann halt durchsucht (das meine ich mit
                                                      logarithmisch im Gegensatz zum succesiven Durchsuchen
                                                      einer Tabelle).

                                                      Ja.

                                                      Aber das müßte doch tierisch schnell sein,

                                                      Nicht zwingend. Bei unguenstigen Daten kann der Baum halt
                                                      sehr schnell degenerieren.

                                                      Gruesse,
                                                       CK

                                                      1. Hi Christian,

                                                        ich fange mal hier an, in den Thread hinein zu kommentieren ... (den meisten Deiner Aussagen kann ich eh nur zustimmen)

                                                        Also wird beim MySQL Volltext irgendwie ein binärer Baum
                                                        auf der Festplatte gespeichert,
                                                        Unwahrscheinlich. Eher ein B-Baum.

                                                        Vermutlich hast Du recht - aber für die aktuelle Diskussion ist das gar nicht wirklich wichtig. Es bestimmt, zu welcher Basis der Logarithmus gebildet wird ... mehr nicht. Deshalb habe ich zur Veranschaulichung jeweils binäre Bäume verwendet. (Natürlich ist innerhalb einer Index-Seite Platz für mehr als zwei Tochterknoten.)

                                                        Aber das müßte doch tierisch schnell sein,
                                                        Nicht zwingend. Bei unguenstigen Daten kann der Baum halt
                                                        sehr schnell degenerieren.

                                                        Das ist ein Aspekt des Betriebskonzepts der Anwendung.

                                                        Wenn in diesem Baum nur sehr selten eingefügt oder gelöscht wird, dann bleibt seine Struktur relativ stabil, wenn diese am Anfang einmal sinnvoll[tm] erzeugt wurde.
                                                        Und auch hierfür ist es besser, zuerst alles Datensätze einzufügen und danach ein CREATE INDEX hinterher zu schießen (was sicherlich auch schneller ist, aber massiv Ressourcen anfordert).

                                                        Viele Grüße
                                                              Michael

                                                        --
                                                        T'Pol: I meant no insult.
                                                        V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                        1. Hallo Michael,

                                                          Also wird beim MySQL Volltext irgendwie ein binärer
                                                          Baum auf der Festplatte gespeichert,
                                                          Unwahrscheinlich. Eher ein B-Baum.

                                                          Vermutlich hast Du recht - aber für die aktuelle
                                                          Diskussion ist das gar nicht wirklich wichtig.

                                                          Korrekt. Ich wollte nur sicher gehen, das Andreas den
                                                          Unterschied zwischen B-Baum und Binaerer Baum verstanden
                                                          hat :)

                                                          Wenn in diesem Baum nur sehr selten eingefügt oder
                                                          gelöscht wird, dann bleibt seine Struktur relativ stabil,
                                                          wenn diese am Anfang einmal sinnvoll[tm] erzeugt wurde.

                                                          Das kommt auf die Daten an. Wenn die Daten genuegend
                                                          entropisch sind, mit Sicherheit, ja. Wenn man aber oft
                                                          dieselben Woerter hat, dann kann ein Baum durchaus leicht
                                                          degenerieren.

                                                          Und auch hierfür ist es besser, zuerst alles Datensätze
                                                          einzufügen und danach ein CREATE INDEX hinterher zu
                                                          schießen (was sicherlich auch schneller ist, aber massiv
                                                          Ressourcen anfordert).

                                                          Fuer MySQL kann ich da nur absolut zustimmen :)

                                                          Gruesse,
                                                           CK

                                                          1. Hi Christian,

                                                            Das kommt auf die Daten an. Wenn die Daten genuegend
                                                            entropisch sind, mit Sicherheit, ja. Wenn man aber oft
                                                            dieselben Woerter hat, dann kann ein Baum durchaus leicht
                                                            degenerieren.

                                                            ich denke, der Baum degeneriert auch dann nicht - denn die Baum-Form ist ja etwas, das der Index-Generator erzwingen kann.

                                                            Allerdings wird es dann große Teilbäume mit den immer gleichen Schlüsselworten geben - die sind immerhin schnell isoliert, aber ihre ganzen Knoten dann zu extrahieren und als Ergebnis zurückzuliefern, das kann teuer werden ("JavaScript" etc.).

                                                            Ein solcher Baum hat dann möglicherweise eine schlechte mittlere Projektivität ... ein schlaues RDBMS kann allerdings via ANALYZE TABLE sowohl diese Projektivität als auch möglicherweise sogar eine blacklist der schlechtesten Suchbegriffe separat zu dieser Tabelle speichern und dies vom Query Optimizer berücksichtigen lassen. Wenn dieser nämlich weiß, daß ein Suchbegriff 30% der Tabelle liefern wird, dann sollte er dringend auf die Verwendung von Indexzugriffen verzichten ... in diesem Falle ist der full table scan wirklich schneller.

                                                            Viele Grüße
                                                                  Michael

                                                            --
                                                            T'Pol: I meant no insult.
                                                            V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                            1. Hallo Michael,

                                                              Allerdings wird es dann große Teilbäume mit den immer
                                                              gleichen Schlüsselworten geben - die sind immerhin schnell
                                                              isoliert, aber ihre ganzen Knoten dann zu extrahieren und
                                                              als Ergebnis zurückzuliefern, das kann teuer werden
                                                              ("JavaScript" etc.).

                                                              Das ist fuer mich eine Form der Degeneration.

                                                              Ein solcher Baum hat dann möglicherweise eine schlechte
                                                              mittlere Projektivität ... ein schlaues RDBMS kann
                                                              allerdings via ANALYZE TABLE sowohl diese Projektivität
                                                              als auch möglicherweise sogar eine blacklist der
                                                              schlechtesten Suchbegriffe separat zu dieser Tabelle
                                                              speichern und dies vom Query Optimizer berücksichtigen
                                                              lassen. Wenn dieser nämlich weiß, daß ein Suchbegriff 30%
                                                              der Tabelle liefern wird, dann sollte er dringend auf die
                                                              Verwendung von Indexzugriffen verzichten ... in diesem
                                                              Falle ist der full table scan wirklich schneller.

                                                              Das kann ich leider nicht beurteilen, dazu fehlen mir die
                                                              Kenntnisse.

                                                              Gruesse,
                                                               CK

                                                              1. Hi Christian,

                                                                speichern und dies vom Query Optimizer berücksichtigen
                                                                lassen. Wenn dieser nämlich weiß, daß ein Suchbegriff 30%
                                                                der Tabelle liefern wird, dann sollte er dringend auf die
                                                                Verwendung von Indexzugriffen verzichten ... in diesem
                                                                Falle ist der full table scan wirklich schneller.
                                                                Das kann ich leider nicht beurteilen, dazu fehlen mir die
                                                                Kenntnisse.

                                                                im Detail wird das immer auch vom RDBMS abhängen. Bei Oracle 7 habe ich "15%" als 'Hausnummer' gelernt - Faktor 2 an Abweichung davon ist wahrscheinlich als "Grauzone" zu betrachten.

                                                                http://www.znow.com/sales/oracle/server.816/a76992/ch6_acce.htm#2913
                                                                ist _eine_ Quelle, die zu diesem Punkt versucht, konkrete Zahlen zu nennen. Der ganze Oracle Performance Tuning Guide (ein eigenes Buch mit mehreren hundert Seiten) ist m. E. ziemlich spannend zu lesen.

                                                                Viele Grüße
                                                                      Michael

                                                                --
                                                                T'Pol: I meant no insult.
                                                                V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                              2. Hi Christian,

                                                                Allerdings wird es dann große Teilbäume mit den immer
                                                                gleichen Schlüsselworten geben - die sind immerhin schnell
                                                                isoliert, aber ihre ganzen Knoten dann zu extrahieren und
                                                                als Ergebnis zurückzuliefern, das kann teuer werden
                                                                ("JavaScript" etc.).
                                                                Das ist fuer mich eine Form der Degeneration.

                                                                für mich nicht.

                                                                Denn in diesem Falle ist nicht der Indexbaum (durch ständige Veränderung) strukturell degeneriert, sondern die Daten sind generell nicht indextauglich.
                                                                So etwas kann keine housekeeping-Funktion des RDMBS automatisch beheben - in diesem Fall ist schon die Datenmodellierung schief gegangen.

                                                                Viele Grüße
                                                                      Michael

                                                                --
                                                                T'Pol: I meant no insult.
                                                                V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                                1. Hallo Michael,

                                                                  Denn in diesem Falle ist nicht der Indexbaum (durch ständige
                                                                  Veränderung) strukturell degeneriert, sondern die Daten sind
                                                                  generell nicht indextauglich.

                                                                  Korrekt.

                                                                  So etwas kann keine housekeeping-Funktion des RDMBS
                                                                  automatisch beheben - in diesem Fall ist schon die
                                                                  Datenmodellierung schief gegangen.

                                                                  Ja. Und genau deshalb halte ich den Fulltext-Index fuer MySQL
                                                                  hier fuer ungeeignet :) Wir haben hier sehr oft sehr aehnliche
                                                                  Daten.

                                                                  Gruesse,
                                                                   CK

                                                                  1. Hi Christian,

                                                                    So etwas kann keine housekeeping-Funktion des RDMBS
                                                                    automatisch beheben - in diesem Fall ist schon die
                                                                    Datenmodellierung schief gegangen.
                                                                    Ja. Und genau deshalb halte ich den Fulltext-Index fuer MySQL
                                                                    hier fuer ungeeignet :) Wir haben hier sehr oft sehr aehnliche
                                                                    Daten.

                                                                    bei den Posting-Inhalten oder bei den Suchbegriffen?

                                                                    Entscheidend wäre ersteres - und da bin ich mir deutlich weniger sicher als bei der zweiten Möglichkeit (wo es sicherlich heftige Ausreißer gibt, etwa "JavaScript" oder "HTML", deshalb ja auch die Idee der blacklist bezüglich Indexzugriffen: Die Chance, in fast jeder Such-Anfrage qualitativ unterschiedliche Suchbegriffe zu finden, halte ich für ziemlich hoch).

                                                                    Viele Grüße
                                                                          Michael

                                                                    --
                                                                    T'Pol: I meant no insult.
                                                                    V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                                    1. Hallo Michael,

                                                                      So etwas kann keine housekeeping-Funktion des RDMBS
                                                                      automatisch beheben - in diesem Fall ist schon die
                                                                      Datenmodellierung schief gegangen.
                                                                      Ja. Und genau deshalb halte ich den Fulltext-Index fuer
                                                                      MySQL hier fuer ungeeignet :) Wir haben hier sehr oft
                                                                      sehr aehnliche Daten.

                                                                      bei den Posting-Inhalten oder bei den Suchbegriffen?

                                                                      Sowohl, als auch. Wobei das zweitere eher egal ist :)

                                                                      Entscheidend wäre ersteres - und da bin ich mir deutlich
                                                                      weniger sicher als bei der zweiten Möglichkeit

                                                                      Das Problem hierbei ist, dass wir sehr, sehr oft immer
                                                                      dieselben Worte haben. Such doch mal nach 'ie', oder nach
                                                                      'nn'. Und bevor du jetzt Blacklist schreist ;): das sind
                                                                      nicht die einzigen. Damit kann man einfach keinen sinnvollen
                                                                      Index aufbauen.

                                                                      Ueberigens sagte Daniela mir, dass Datenbanken B*-Baeume
                                                                      benutzen. FYI :)

                                                                      Gruesse,
                                                                       CK

                                                                      1. Hi Christian,

                                                                        Das Problem hierbei ist, dass wir sehr, sehr oft immer
                                                                        dieselben Worte haben. Such doch mal nach 'ie', oder nach
                                                                        'nn'. Und bevor du jetzt Blacklist schreist ;): das sind
                                                                        nicht die einzigen.

                                                                        sondern? Wie viele Worte liefern, sagen wir mal: mehr als 1% aller Postings zurück? Und wieviel Prozent aller Worte sind das? Über diese Teilmenge läßt sich prima ein schnuckeliger kleiner Blacklist-Index bauen.

                                                                        Damit kann man einfach keinen sinnvollen Index aufbauen.

                                                                        Eine so absolute Aussage halte ich nicht für flexibel genug, um dem Problem angemessen zu sein.

                                                                        Viele Grüße
                                                                              Michael

                                                                        --
                                                                        T'Pol: I meant no insult.
                                                                        V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                                        1. Hallo Michael,

                                                                          sondern? Wie viele Worte liefern, sagen wir mal: mehr als
                                                                          1% aller Postings zurück? Und wieviel Prozent aller Worte
                                                                          sind das? Über diese Teilmenge läßt sich prima ein
                                                                          schnuckeliger kleiner Blacklist-Index bauen.

                                                                          Soo, jetzt hab ich etwas, womit ich argumentieren kann:

                                                                          </count_stopwords.txt>

                                                                          Das ganze nochmal ohne Stopwords:

                                                                          </count.txt>

                                                                          Das Script, das den Output erzeugt hat, ist recht einfach:

                                                                          </indizes.txt>

                                                                          Damit kann man einfach keinen sinnvollen Index aufbauen.

                                                                          Eine so absolute Aussage halte ich nicht für flexibel
                                                                          genug, um dem Problem angemessen zu sein.

                                                                          Hrhr ;)

                                                                          Gruesse,
                                                                           CK

                                                                          1. Hi Christian,

                                                                            sondern? Wie viele Worte liefern, sagen wir mal: mehr als
                                                                            1% aller Postings zurück? Und wieviel Prozent aller Worte
                                                                            sind das? Über diese Teilmenge läßt sich prima ein
                                                                            schnuckeliger kleiner Blacklist-Index bauen.

                                                                            Soo, jetzt hab ich etwas, womit ich argumentieren kann:
                                                                            </count_stopwords.txt>

                                                                            wunderbar. Und davon jetzt die obersten 500 Worte auf die schwarze Liste, so daß für sie keine WHERE-Klausel mit FULLTEXT-Zugriff generiert wird, sofern noch bessere Begriffe angegeben wurden (und Zurückweisen der Such-Anfrage, falls nicht!), sondern der nachgeschaltete Phrasenfilter damit betraut wird, sie zu validieren.

                                                                            Genau das war es, was ich haben wollte.

                                                                            Viele Grüße
                                                                                  Michael

                                                                            --
                                                                            T'Pol: I meant no insult.
                                                                            V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                    2. Hi Andreas,

                                                      Warum sollte man Woerter doppelt speichern? Du kannst
                                                      stattdessen die Wertigkeit mitspeichern, in einer weiteren
                                                      Spalte.
                                                      Das hatte ich jetzt Michaels Aussage entnommen, dass man nur eine Tabelle verwendet, mit je Wort => Posting_ID, und dann könnte man über Wort einen Index legen ung hätte dann auch sowas wie eine logarithmische Suche, da im Index ja auch nur jedes Wort 1 mal vorkommt,

                                                      Im Index kommt jedes Wort ziemlich oft vor - mindestens so oft, wie Du zu einem Suchbegriff verschiedene Treffer-Dokumente finden können willst.
                                                      "wort -> dokument" ist eine m:n-Beziehung.
                                                      Dein Tabellenmodell versucht, diese m:n-Beziehung durch zwei Tabellen zu realisieren, die jeweils eine 1:n-Beziehung speichern, und diese per JOIN zu verknüpfen (oder einen Übersetzungs-Schritt per separatem SQL-Statement durchführen, was auch nicht ganz unsonst ist - das könntest Du allerdings über eine Hashing-Funktion ohne Datenbankzugriff versuchen); das spart Speicher, kostet aber Zeit. Da Du gerade dabei bist, Zeit zu erkaufen, indem Du Speicher investierst, solltest Du an dieser Stelle vielleicht _nicht_ in die _entgegengesetzte_ Richtung optimieren, sondern doch lieber redundante Repräsentationen der Suchbegriffe speichern - das war meine Idee dabei.

                                                      Ich überlege halt eienn Fulltext-Index manuell in einer, bzw. 3 Tabellen nachzubilden. Das würde ich dann wenigstens verstehen und könnte das entsprechend versuchen anzupassen.

                                                      Wenn das Ganze auf einer nicht-mySQL-Datenbank auf dem Self-Server laufen soll und Du das Funktionsprinzip beibehalten willst, wird Dir eine "Emulation" von FULLTEXT durch eine eigene Tabelle nicht erspart bleiben. (Deshalb habe ich diesen Diskussions-Strang forciert.)

                                                      Woher weiß ich vorher was der User als nächstes in der DB
                                                      sucht?
                                                      Gar nicht. Warum solltest du das wissen muessen? Behalte die
                                                      durchschnittlich am meisten gebrauchten Teile permanent im
                                                      Speicher und gut.
                                                      Das ist das was sowohl mein Filesystem als auch der MySQL-Cache tut, nur wenn man sich mal so Suchanfragen ansieht, dann sind die doch sehr verschieden.

                                                      Das macht nichts.

                                                      Das Problem ist das ca. 90% der Suchanfragen sehr selten sind. Die kann man nicht alle im Cache halten,

                                                      Das ist wahr. Aber es ist nicht wirklich teuer, den Abstieg durch 10 Seiten innerhalb des Indexbaums zu machen. Es ist sehr viel teurer, 1000 Seiten voller Treffer auf der Suche nach "JavaScript"-Postings von der Festplatte zu lesen, nur um anschließend festzustellen, daß man davon 99% besser gar nicht erst gelesen hätte. Und dieses "gar nicht erst lesen" ist der Trick.

                                                      die 10% die öfter sind, gut, aber die nicht gecachten seltenen Anfragen müssen jedesmal im kompleten Index gesucht werden, der Volltext Index für den gesamten Self-Raum hätte bestimmt 250 MB, der müßte dann also komplett einmal geparst werden,

                                                      Nein. Die Knoten des Baums liegen auf separaten Bereichen der Festplatte. Du mußt wirklich nur diejenigen Teile des Indexbaums lesen, die für Deine aktuelle Suche von Interesse sind. Und das sind sehr viel weniger als 100%.

                                                      durchsucht werden und dann müßten die Daten der Ergebnisse noch aus der Tabellen-Datei von der Platte geholt werden, aber das ist dann das geringste Problem. ODer habe ich das jetzt total faslch verstanden? ODer muß der Index nicht geparst werden?

                                                      Du _navigierst_ innerhalb des Index. Die Geschwindigkeit beim Zugriff auf die gewünschten Informationen basiert exakt darauf, _nicht_ den kompletten Index lesen zu müssen, sondern sich von Ebene zu Ebene in immer tiefere Teilbäume vorzutasten. Du liest nicht zuerst den kompletten Index ein und suchst anschließend etwas in diesem - Du liest zuerst die Wurzelseite des Indexbaums und prüfst innerhalb dieser Liste, welche Seiten der 1. Ebene Du für Deinen Indexzugriff benötigst (das werden fast immer nur sehr wenige sein, etwa eine oder höchstens zwei, falls Dein Suchbegriff zufällig genau an der "Kante" zwischen zwei Teilbäumen liegt). Für die so ausgewählten Unterseiten führst Du dieselbe Operation rekursiv wieder aus.

                                                      Dabei werden die meisten Suchvorgänge dieselben Indexseiten der obersten Ebenen einlesen. Diese haben eine hohe Cache-Hit-Rate und werden deshalb vom Betriebssystem permanent im Hauptspeicher gehalten. Angenommen, der Baum adressiert eine Million Postings, hat also eine Höhe von 20 binären Knoten, dann könnte man problemlos die obersten 15 Ebenen komplett im Hauptspeicher halten, weil sie nur 1/(2^5) = 3,125% des Indexbaums ausmachen. Nur für die untersten fünf Ebenen, also ein Viertel der Index-Navigationsschritte, müßtest Du auf Seiten der Festplatte zugreifen. (Bei der Verwendung von B-Bäumen statt binären Bäumen wird das Verhältnis eher noch günstiger, vermute ich.)

                                                      Also wird beim MySQL Volltext irgendwie ein binärer Baum auf der Festplatte gespeichert, und der wird dann halt durchsucht(das meine ich mit logarithmisch im Gegensatz zum succesiven Durchsuchen einer Tabelle). Aber das müßte doch tierisch schnell sein, ist es aber nicht.

                                                      Das Finden ist immer tierisch schnell, denn seine Dauer ist unabhängig von den verwendeten Suchbegriffen - vorausgesetzt, Du verwendest kein AND zwischen mehreren MATCH()es (denn das wiederum kostet einen JOIN, und der ist ggf. sehr teuer).
                                                      Auch das Zurückliefern der gefundenen Ergebnisse ist keineswegs immer gleich schnell, denn das ist abhängig von der _Anzahl_ der gefundenen Treffer. Und da die Suche aus der Kombination von Finden und Ausliefern besteht, wird eine Suche nach "Ratzelfatz" immer schneller sein als eine Suche nach "Javascript". Und vor allem wird eine Suche nach "Ratzelfatz" schneller sein als eine Suche nach "Ratzelfatz AND JavaScript". Dieser Geschwindigkeitsunterschied muß jedoch möglichst klein werden - das muß das Ziel Deiner Generierung von SQL-Code sein.

                                                      Mach mal eine Suche nach einem Begriff, der überhaupt nicht vorkommt. Dann hast Du ein realistisches Maß für die maximale Finde-Geschwindigkeit. Anschließend sollte das Ziel darin bestehen, bei möglichst vielen Suchvorgängen relativ nahe an diese Geschwindigkeit heran zu kommen und bei möglichst vielen der rechtlichen Suchvorgänge schon vor der Suche zu erkennen, daß sie sehr langsam sein werden. Eine Suche nach "JavaScript" ohne weitere Suchbegriffe muß Deine Oberfläche erkennen und zurückweisen.

                                                      Viele Grüße
                                                            Michael

                                                      --
                                                      T'Pol: I meant no insult.
                                                      V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                2. Hi Andreas,

                                                  Was ich jetz imme rnoch nicht genau verstanden habe -
                                                  erstellt FULLTEXT jetzt eine interne Tabelle wie oben,
                                                  oder einen B-Baum?
                                                  Wo ist der Unterschied?
                                                  Ich dachte immer ein Binärer Baum würde bei einem Wort anfangen und sich dann weiter verzweigen, wie man das ganze "statisch" speichern soll ist dann so eien Sache die ich noch nicht wirklich verstanden  habe, aber das soll wohl gehen. Eine Tabelle wird ja nur linear durchsucht.

                                                  Eine Tabelle wird so durchsucht, wie der Query Optimizer das entscheidet. Wenn zu einer Tabelle kein einziger Index vorliegt, dann gibt es keinen 'schlaueren' Ausführungsplan als die lineare Suche. Liegt jedoch mindestens ein Index vor, dann _kann_ dieser Index dafür geeignet sein, einen logarithmischen Zugriff zu ermöglichen (falls er über passende Spalten geht, die in der WHERE-Klausel und/oder in der ORDER BY-Klausel verwendet wurden).

                                                  Das heisst, dass *nicht* der komplette Index im Speicher
                                                  gehalten wird, sondern nur teilweise im Speicher behalten
                                                  werden braucht.
                                                  aber welcher Teil? Woher weiß ich vorher was der User als nächstes in der DB sucht?

                                                  Woher weiß das Betriebssystem, welchen Teil eines laufenden Programms es auslagern kann, weil Du gerade ein neues Programm starten willst und dafür freien Speicher benötigst? Es weiß nicht wirklich, was Du willst - aber es wendet einen Algorithmus an, der im Mittel zu einer möglichst geringen Anzahl von Seitenaustauschoperationen führen wird.

                                                  Warum sollte sie? Dateien sind nicht sequentiell. Man darf
                                                  durchaus auch nur 10 Byte in der Mitte auslesen, oder 100
                                                  Byte am Anfang.
                                                  OK, aber woher weiß ich jetzt welche 10 Byte ich genau raushole? Wenn ich den Index nicht im Speicher habe, muß ich doch bei einer Anfrage erstmal den kompletten Index in den Speicher laden, um dann mit Hilfe des Index(denn ich einmal komplett parsen muß) den Teil der Tabellendatei zu ermitteln, den ich jetzt gut gebrauchen könnte, oder? Das Problem ist nur das der Index selbst zu groß ist für den RAM! Zumindest wenn gleichzeitig noch andere Software laufen soll.

                                                  Du kannst den Index auch in Teilen verarbeiten. Und diese Teile können sehr klein sein. Eine Index-Suche besteht aus (logarithmisch) vielen einzelnen Schritten. Jeder dieser Schritte greift nur auf ganz wenige Seiten zu - und sein Ergebnis ist jeweils eine Liste von Seiten für den nächsten Schritt. Nach und nach werden dabei immer kleinere Teile des Baums immer genauer abgegrenzt, bis am Ende eine Liste von Blättern als Ergebnis vorliegt. Ganze Teilbäume, in denen kein Treffer liegen kann, werden oftmals schon in den ersten Schritten als solche erkannt und nicht mehr bearbeitet - ihr Inhalt muß also bei dieser Suche nicht im Hauptspeicher liegen.

                                                  Unwahrscheinlich. Wenn, dann nicht merkbar. String-Indizes
                                                  sind im Normalfall Hashing-Indizes, und die sind nicht
                                                  wirklich langsamer als Zahlen-Indizes.
                                                  Ja? Das hat mir jemand mal ganz anders erklärt, dass ein String-Vergleich vor allem in größeren Tabellen erheblich länger dauert als ein Integer-Vergleich.

                                                  Selbst bei längeren und variabel langen Zeichenketten werden sich die Zusatzkosten in Grenzen halten - wobei ich Christians Vermutung, daß eine Hash-Funktion verwendet wird, nicht uneingeschränkt teilen kann, denn dann wäre der Index für Präfixzugriffe unbrauchbar, denke ich ...

                                                  Viele Grüße
                                                        Michael

                                                  --
                                                  T'Pol: I meant no insult.
                                                  V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                  1. Hi Michael

                                                    Selbst bei längeren und variabel langen Zeichenketten werden sich die Zusatzkosten in Grenzen halten - wobei ich Christians Vermutung, daß eine Hash-Funktion verwendet wird, nicht uneingeschränkt teilen kann, denn dann wäre der Index für Präfixzugriffe unbrauchbar, denke ich ...

                                                    Das mit den Präfixzugriffen interessiert mich jetzt. Ich muss gestehen, ich
                                                    kenn mich mit Hashingfunktionen nicht sonderlich gut aus, habe jedoch
                                                    nirgendwo Warnungen gesehen beim Hash-Indexbeschrieb von PostgreSQL, und
                                                    die würde ich erwarten wenn das nicht funktionieren würde. Wenn ich
                                                    das richtig verstehe, müsste ja ein Hashingkey auf einen String besser
                                                    geeignet sein als eine normaler Index.

                                                    Weist du etwas gutes zu lesen zu Hashing-Funktionen?

                                                    Es würde mich auch interessieren was du vom neuen Suchkonzept hälst
                                                    so weit das schon steht, aber nicht hier öffentlich sondern per Mail.
                                                    Ich war bisher zu faul nach deiner Mailadresse zu suchen.

                                                    Gruss Daniela

                                                    1. Hallo Daniela,

                                                      Selbst bei längeren und variabel langen Zeichenketten
                                                      werden sich die Zusatzkosten in Grenzen halten - wobei
                                                      ich Christians Vermutung, daß eine Hash-Funktion
                                                      verwendet wird, nicht uneingeschränkt teilen kann, denn
                                                      dann wäre der Index für Präfixzugriffe unbrauchbar,
                                                      denke ich ...

                                                      Korrekt. Indizes koennen ja fuer Praefix-Zugriffe auch nicht
                                                      benutzt werden. ein 'LIKE "%blahr"' kann nicht ueber den
                                                      Index ausgewertet werden (zumindest wuesste ich nicht, wie
                                                      das gehen sollet).
                                                      Fuer *Suffix*-Zugriffe kommt es darauf an, was fuer eine
                                                      Aber du hast recht, ein Hashing-Index eignet sich aeusserst
                                                      schlecht fuer derartige Zugriffe. Ich glaub, ich war etwas
                                                      voreilig und haette besser sagen sollen, es *gibt* auch
                                                      Hashing-Indizes :)

                                                      Wenn ich das richtig verstehe, müsste ja ein Hashingkey
                                                      auf einen String besser geeignet sein als eine normaler
                                                      Index.

                                                      Der Zugriff ist schneller, ja. Eine schnelle Hash-Funktion
                                                      braucht 6xLength(key)+32 Zyklen um eine Hash-Sum auszurechen.
                                                      Der Lookup in der Tabelle braucht dann nochmal etwa sechs
                                                      Zyklen, wenn ich das richtig in Erinnerung habe (ins Register
                                                      holen, Addieren, Multiplizieren, ins Register holen). Dann
                                                      waeren wir bei 6xLength(key) + 38 Zyklen fuer einen
                                                      Hash-Lookup bei der Annahme, dass die Hash-Funktion perfekt
                                                      ist (was sie natuerlich bei endlicher Schluessellaenge nicht
                                                      sein kann).

                                                      Weist du etwas gutes zu lesen zu Hashing-Funktionen?

                                                      http://burtleburtle.net/bob/hash/evahash.html#universal

                                                      fand ich sehr interessant. Ansonsten vielleicht noch

                                                      http://www.x5.net/faqs/crypto/q94.html

                                                      Ich war bisher zu faul nach deiner Mailadresse zu suchen.

                                                      http://www.schroepl.net/ :)

                                                      Gruesse,
                                                       CK

                                                      1. Hi Christian

                                                        Korrekt. Indizes koennen ja fuer Praefix-Zugriffe auch nicht
                                                        benutzt werden. ein 'LIKE "%blahr"' kann nicht ueber den
                                                        Index ausgewertet werden (zumindest wuesste ich nicht, wie
                                                        das gehen sollet).

                                                        Upsi, ich meinte natürlich Postfix-Zugriffe, Präfix-Zugriffe
                                                        sind ja eh... Naja, da hab ich ja eh schon abgekupfert von
                                                        Michael um das Problem zu umgehen.

                                                        Fuer *Suffix*-Zugriffe kommt es darauf an, was fuer eine
                                                        Aber du hast recht, ein Hashing-Index eignet sich aeusserst
                                                        schlecht fuer derartige Zugriffe. Ich glaub, ich war etwas
                                                        voreilig und haette besser sagen sollen, es *gibt* auch
                                                        Hashing-Indizes :)

                                                        Auch für Postfixzugriffe? Habs den ersten Satz nicht verstanden
                                                        und ich werde gelyncht wenn ich jetzt deine Links nachlese.

                                                        Der Zugriff ist schneller, ja. Eine schnelle Hash-Funktion
                                                        braucht 6xLength(key)+32 Zyklen um eine Hash-Sum auszurechen.
                                                        Der Lookup in der Tabelle braucht dann nochmal etwa sechs
                                                        Zyklen, wenn ich das richtig in Erinnerung habe (ins Register
                                                        holen, Addieren, Multiplizieren, ins Register holen). Dann
                                                        waeren wir bei 6xLength(key) + 38 Zyklen fuer einen
                                                        Hash-Lookup bei der Annahme, dass die Hash-Funktion perfekt
                                                        ist (was sie natuerlich bei endlicher Schluessellaenge nicht
                                                        sein kann).

                                                        Nützt nur nichts wenn das für Postfixsuchen nicht brauchbar ist.

                                                        Btw klappt deine Berechnung mit den Zyklen nicht da es sehr
                                                        verschieden ist, wie viele Zyklen ein Prozessor für die einzelnen
                                                        Befehle braucht und ob er die Daten wirklich in ein Register holt.
                                                        Je nach dem kann er das gar nicht da ein Register ein Wort (ursprüngliche
                                                        Definition) lang ist.

                                                        Weist du etwas gutes zu lesen zu Hashing-Funktionen?

                                                        [..]

                                                        Werd ich zuhause lesen, danke.

                                                        Gruss Daniela

                                                        1. Hallo Daniela,

                                                          Fuer *Suffix*-Zugriffe kommt es darauf an, was fuer eine

                                                          Ups. Das musst du streichen, das gehoert da nicht hin.

                                                          Auch für Postfixzugriffe?

                                                          Unwahrscheinlich, kommt aber auf die Hashing-Funktion an.
                                                          Mathematisch ist das natuerlich moeglich. Allerdings ist dann
                                                          ein Table-Lookup nicht mehr moeglich ;)

                                                          Nützt nur nichts wenn das für Postfixsuchen nicht
                                                          brauchbar ist.

                                                          Dafuer ist Hashing auch nicht gedacht.

                                                          Btw klappt deine Berechnung mit den Zyklen nicht da es
                                                          sehr verschieden ist, wie viele Zyklen ein Prozessor für
                                                          die einzelnenBefehle braucht

                                                          Korrekt. Deshalb ist das natuerlich als ein Mittelmass zu
                                                          verstehen :)

                                                          und ob er die Daten wirklich in ein Register holt.

                                                          Kommt wohl auf die Umsetzung an. Wenn der Compiler gut
                                                          optimiert, muss nur 2x etwas ins Register geholt werden.

                                                          Gruesse,
                                                           CK

                                                          1. Hi Christian

                                                            Unwahrscheinlich, kommt aber auf die Hashing-Funktion an.
                                                            Mathematisch ist das natuerlich moeglich. Allerdings ist dann
                                                            ein Table-Lookup nicht mehr moeglich ;)

                                                            Weist du wie sich eine Hashingfunktion bei vielen Dubletten verhält?
                                                            Insbesondere interessiert mich natürlich, wie sich PostgreSQL mit
                                                            einem Hashingindex dann verhält. Ich frag mich nämlich gerade,
                                                            ob die mühsamen Joins wirklich nötig sind, oder ob ich direkt
                                                            die Worte kombiniert mit dem Eintrag als Key benutzen soll und
                                                            darüber einen Hashingindex benutzen kann.

                                                            Nützt nur nichts wenn das für Postfixsuchen nicht
                                                            brauchbar ist.

                                                            Dafuer ist Hashing auch nicht gedacht.

                                                            Möglich, wäre aber sehr bequem wenn das geht, würde mir vorallem
                                                            beim indizieren n Haufen abfragen und bestehende Keys holen
                                                            ersparen.

                                                            und ob er die Daten wirklich in ein Register holt.

                                                            Kommt wohl auf die Umsetzung an. Wenn der Compiler gut
                                                            optimiert, muss nur 2x etwas ins Register geholt werden.

                                                            Wenn er aber findet, er braucht etwas zu wenig häufig, wird er
                                                            es gar nicht ins Register holen. Bei C zb kann mans ihm jedoch
                                                            empfehlen (aber nicht erzwingen). Bei gcc ists teilweise
                                                            ziemlich witzig was er da an Assembler produziert, zumindest
                                                            die Version die Code für 680x0 produziert.

                                                            Gruss Daniela

                                                            1. Hallo Daniela,

                                                              Weist du wie sich eine Hashingfunktion bei vielen
                                                              Dubletten verhält?

                                                              Die Hashing-Funktion verhaelt sich gar nicht. Das
                                                              Hashtable-Framework (urghs, bloedes Buzzword, aber mir faellt
                                                              leider nichts besseres ein) reagiert damit in der Regel
                                                              darauf, dass es die Key-Laenge vergroessert und den Hash
                                                              komplett restrukturiert.

                                                              Eine Hashing-Funktion liefert idR Hash-Summen der Laenge
                                                              32 Bit oder 64 Bit (je nach dem, auf welcher Architektur sie
                                                              eingesetzt wird). Das ist natuerlich viel zu viel, denn wenn
                                                              man garantieren wollte, dass eine Hash-Summe immer innerhalb
                                                              des Bereichs der Tabelle ist, muesste man sie 2^32 bzw. 2^64
                                                              Eintraege gross machen. Deshalb wird idR mit etwa 10 Bit
                                                              angefangen, 2^10 = 1024, mit einem 1024 Elemente grossem
                                                              Array kann man noch leben. Wenn jetzt allerdings zu viele
                                                              Doubletten auftreten, wird die Keylaenge um ein Bit
                                                              vergroessert: statt 10 Bit verwendet man 11 Bit. Dafuer muss
                                                              aber jetzt die komplette Hash-Tabelle restrukturiert werden.
                                                              Fuer jeden Eintrag muss eine neue Position benutzt werden,
                                                              denn mit der neuen Key-Laenge sind die Summen natuerlich
                                                              nicht mehr gleich.

                                                              Insbesondere interessiert mich natürlich, wie sich
                                                              PostgreSQL mit einem Hashingindex dann verhält.

                                                              Das kann ich dir nicht sagen, ich habe nicht in den Source
                                                              geschaut, sorry.

                                                              Ich frag mich nämlich gerade, ob die mühsamen Joins
                                                              wirklich nötig sind, oder ob ich direkt die Worte
                                                              kombiniert mit dem Eintrag als Key benutzen soll und
                                                              darüber einen Hashingindex benutzen kann.

                                                              Du meinst wahrscheinlich nicht Dupletten, sondern doppelte
                                                              Eintraege. Das ist ein Unterschied. Eine Duplette ist ein
                                                              Eintrag, der dieselbe Hashsumme wie ein anderer Eintrag mit
                                                              einem anderen Key hat.
                                                              Wie PostGreSQL doppelte Eintraege verwaltet, kann ich dir
                                                              leider nicht sagen. Ich koennte mir vorstellen, dass es in
                                                              jedem Hash-Element eine lin. Liste gibt.

                                                              Möglich, wäre aber sehr bequem wenn das geht, würde mir
                                                              vorallem beim indizieren n Haufen abfragen und bestehende
                                                              Keys holen ersparen.

                                                              Mag sein. Es ist aber nicht moeglich, es sei denn, PostGreSQL
                                                              wuerde pro Key nicht einen, sondern len Eintraege in die
                                                              Tabelle machen, den Key immer um ein Bit kuerzer. Und das
                                                              kann ich mir echt nicht vorstellen.

                                                              Wenn er aber findet, er braucht etwas zu wenig häufig,
                                                              wird er es gar nicht ins Register holen.

                                                              Korrekt. Aber idR kann man fuer eine Architektur recht gut
                                                              vorraussagen, was im Register landet und was nicht.

                                                              Gruesse,
                                                               CK

                                                              1. Hi Christian

                                                                Möglich, wäre aber sehr bequem wenn das geht, würde mir
                                                                vorallem beim indizieren n Haufen abfragen und bestehende
                                                                Keys holen ersparen.

                                                                Mag sein. Es ist aber nicht moeglich, es sei denn, PostGreSQL
                                                                wuerde pro Key nicht einen, sondern len Eintraege in die
                                                                Tabelle machen, den Key immer um ein Bit kuerzer. Und das
                                                                kann ich mir echt nicht vorstellen.

                                                                Wieso sollte es das? Ist ja kein Unique-Key, resp nur Teil
                                                                von einem Unique-Key.

                                                                Es wäre ja nur anstelle dass das Schlüsselwort erst in eine Nummer
                                                                umgewandelt wird, wird direkt das Schlüsselwort als Index verwendet.

                                                                Anstelle das da Einträge sind wie
                                                                1 1
                                                                1 2
                                                                2 1
                                                                2 3...

                                                                wären da eben
                                                                asdf 1
                                                                asdf 2
                                                                blub 1
                                                                blub 3

                                                                Der Primärschlüssel liegt in jedem Fall über beiden Spalten (ich
                                                                sehe keinen Sinn in den häufig verwendeten inhaltslosen Primärschlüsseln
                                                                nur um diese Situation zu vermeiden). Im Prinzip würde ich das Verhalten
                                                                der Datenbank bei Indizes mit erster Version nur Nachahmen, denke jedoch,
                                                                das die Datenbank so etwas bei weitem selber optimaler kann. Zudem erspart
                                                                es mir wie gesagt die Auflösung zum nummerischen Key beim Schreiben. Natürlich
                                                                geht das zu Lasten des Festplattenplatzes da die vielen Wörter ja n-fach
                                                                gespeichert werden anstelle nur einen kleinen numerischen Key.

                                                                Gruss Daniela

                                                                1. Hallo Daniela,

                                                                  Mag sein. Es ist aber nicht moeglich, es sei denn,
                                                                  PostGreSQL wuerde pro Key nicht einen, sondern len
                                                                  Eintraege in die Tabelle machen, den Key immer um ein
                                                                  Bit kuerzer. Und das kann ich mir echt nicht vorstellen.

                                                                  Wieso sollte es das? Ist ja kein Unique-Key, resp nur Teil
                                                                  von einem Unique-Key.

                                                                  Bei der Generierung einer Hash-Summe wirkt sich jedes Byte
                                                                  des Keys auf jedes Bit der Summe aus. Heisst: um einen
                                                                  Postfix-Lookup zu ermoeglichen, muesste man... hm. Wenn ich
                                                                  gerade drueber nachdenke, ein Postfix-Lookup ist auf keinen
                                                                  Fall moeglich. Ich hatte nicht daran gedacht, das
                                                                  'Postfix-Lookup' nicht bedeutet, einen Teilstring-Lookup zu
                                                                  machen, sondern ein Wildcard-Lookup zu machen. Und das ist
                                                                  bei Hashes nicht moeglich. Der Zugriff geschieht nicht
                                                                  direkt, sondern indirekt ueber den Zwischenschritt der
                                                                  Hash-Summe.

                                                                  Gruesse,
                                                                   CK

                                                                2. Hi Daniela,

                                                                  Anstelle das da Einträge sind wie
                                                                  1 1
                                                                  1 2
                                                                  2 1
                                                                  2 3...

                                                                  wären da eben
                                                                  asdf 1
                                                                  asdf 2
                                                                  blub 1
                                                                  blub 3

                                                                  Der Primärschlüssel liegt in jedem Fall über beiden Spalten

                                                                  ... weil der Zugriff in die zweite Schlüssel-Komponente schneller ist als ein Zugriff auf den Inhalt der tatsächlichen Zeile, ja?

                                                                  sehe keinen Sinn in den häufig verwendeten inhaltslosen Primärschlüsseln
                                                                  nur um diese Situation zu vermeiden). Im Prinzip würde ich das Verhalten
                                                                  der Datenbank bei Indizes mit erster Version nur Nachahmen, denke jedoch,
                                                                  das die Datenbank so etwas bei weitem selber optimaler kann.

                                                                  Wer "optimal" steigert, der frißt auch kleine Kinder. (Lord Helmchen, schreiten Sie zur Tat! ;-)

                                                                  Natürlich geht das zu Lasten des Festplattenplatzes da die vielen Wörter ja n-fach
                                                                  gespeichert werden anstelle nur einen kleinen numerischen Key.

                                                                  Wenn ich Dich recht verstehe, dann beschreibst Du dasselbe, was ich auch schon Andreas gegenüber diskutiert hatte: An dieser Stelle lieber etwas mehr Speicher verbraten als einen zusätzlichen JOIN zu investieren.

                                                                  Viele Grüße
                                                                        Michael

                                                                  --
                                                                  T'Pol: I meant no insult.
                                                                  V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                                  1. Hallo Ihr Informatiker!

                                                                    Da hat sich ja wohl mal wieder eine recht "interessante" Diskussion entwickelt, interessant in "" weil ich mit jedem weiteren Posting immer weniger vestehe und nachvollziehen kann ;-)

                                                                    Anstelle das da Einträge sind wie
                                                                    1 1
                                                                    1 2
                                                                    2 1
                                                                    2 3...

                                                                    wären da eben
                                                                    asdf 1
                                                                    asdf 2
                                                                    blub 1
                                                                    blub 3

                                                                    Der Primärschlüssel liegt in jedem Fall über beiden Spalten

                                                                    Wenn ich Dich recht verstehe, dann beschreibst Du dasselbe, was ich auch schon Andreas gegenüber diskutiert hatte: An dieser Stelle lieber etwas mehr Speicher verbraten als einen zusätzlichen JOIN zu investieren.

                                                                    Ist denn ein Join _so_ teuer? Wenn ich mal rechne das man mit den Strings an Stelle von IDs, also INTRGER Werten, arbeite, dann dürfte sich bei der open zitierten Tabelle doch der Speicherplatzverbrauch mal eben ver-4-fachen(z.B.), aber das ist ja egal, nur das sich hierduch ja auch die Zugriffzeit auf die Festplatte ver-4-facht, alle Datenströme im System dies betreffend verlangsamen sich um den Fakter 4, der nicht unbdingt zu beeinflußende RAM-Sperplatz sinkt auf 1/4, es wird 4 mal mehr "geswappt", also werden wieder _nochmal_ mnehr Plattenzugriffe notwendig....
                                                                    Das ist doch ein Domino-Effekt, "theoretisch" ist das ganze am Ende zw. 3-5 mal so langsam wie mit INTEGER-Werten. Und das macht der fehlende JOIN dann alles wieder wett?

                                                                    Und nur kurz - woher habt Ihr auf einmal das mit dem HASH-Index? Gibt es sowas implementiert in PostGresSQL? Oder ist das jetzt "nur" Theorie?

                                                                    @Daniela: Besteht die Möglichkeit das ich mir mal was zu der neuen Such-Funktion angucken kann? Würde mich brennend interessieren! Ich habe meien Versuche mit einer Suche ursprünglich begonnen, da ich zeitweise nicht auf die aktuelle Suche zugreifen konnte und so meine alten Beiträge, bzw. Antworten auf darin gestellte Fragen nicht finden konnte, also dachte ich mir lädst Du Dir mal eben das Archiv, packst das ganze in eine MySQL-Tabelle, nen schönen Fulltext-Index drüber und fertig ist die Suche die mind. 10 mal so schnell(oder war es 100 oder noch mehr? ;-)) ist wie Michaels aktuelle...
                                                                    Naja, daraus wurde dann erstmal nichts und ich wurde auf den Boden der Tatsachen zurückgeholt. Dann habe ich vor allem durch Michaels Beiträge ne ganze Menge über Datenbanken und Suchalgorithmen(wenn man das so nenne kann) gelernt, und es wurde immer interessanter, daher interessiert es mich sehr wie Du das ganze angehst und löst. Wie Du sicher gemerkt hast fehlt mir leider ne ganze Menge Hintergrundwissen, aber ich habe mit der Suche wirklich in recht kurzer Zeit so viel gelernt wie noch nie. Und in diesem Thread geht´s munter weiter ;-)

                                                                    Ach ja, heute morgen hatte ich eine nette Pflichtveranstaltung "Basistechnologiern des E-Business"(Wirtschaftsinformatik), naja, 3 Stunden Anwesenheitspflicht und habe mal so richtig die Grundlagen von HTML gelernt, so richtig schön mit <font>... und der Verweis auf SELFHTML war auch dabei ;-)

                                                                    Viele Grüße
                                                                    Andreas

                                                                    1. Hallo Andreas,

                                                                      Da hat sich ja wohl mal wieder eine recht "interessante"
                                                                      Diskussion entwickelt, interessant in "" weil ich mit
                                                                      jedem weiteren Posting immer weniger vestehe und
                                                                      nachvollziehen kann ;-)

                                                                      Frag nach.

                                                                      Und nur kurz - woher habt Ihr auf einmal das mit dem
                                                                      HASH-Index? Gibt es sowas implementiert in PostGresSQL?
                                                                      Oder ist das jetzt "nur" Theorie?

                                                                      Nein, den gibt es wirklich bei PostGreSQL.

                                                                      Gruesse,
                                                                       CK

                                                                  2. Hi Michael

                                                                    Der Primärschlüssel liegt in jedem Fall über beiden Spalten

                                                                    ... weil der Zugriff in die zweite Schlüssel-Komponente schneller ist als ein Zugriff auf den Inhalt der tatsächlichen Zeile, ja?

                                                                    Ehm, nein. Weil eine der beiden Spalten den Datensatz nicht identifizieren kann. Alternative wäre eben so ein ekeliges,
                                                                    inhaltsleeres zusätzliches Feld.

                                                                    Natürlich geht das zu Lasten des Festplattenplatzes da die vielen Wörter ja n-fach
                                                                    gespeichert werden anstelle nur einen kleinen numerischen Key.

                                                                    Wenn ich Dich recht verstehe, dann beschreibst Du dasselbe, was ich auch schon Andreas gegenüber diskutiert hatte: An dieser Stelle lieber etwas mehr Speicher verbraten als einen zusätzlichen JOIN zu investieren.

                                                                    Ja und nein, ich schätze nicht, das der zusätzliche Join beim lesen so extrem ins Gewicht fällt. Es kommt ja nur ein Zusatzzugriff auf einen Teil des Primärschlüssels hinzu. Beim Schreiben macht es jedoch einen grossen Unterschied, ob ich
                                                                    erst lesen muss ob es das Schlüsselwort schon gibt, dann wenn
                                                                    es nicht existiert schreiben und dann meinen effektiven Verknüpfungseintrag machen muss. Kommt jedoch der Teilwortindex (von dir geklaut) ins Spiel, muss ich eh erst lesen ob es das Schlüsselwort schon gibt und wenn nicht, die einzelnen Teilwörter schreiben wenn noch nicht existent. Ok, von dem her gesehen ist das auch nicht nötig, und da ein Hashkey nach der Christian mehr oder weniger ins Wasser fällt...

                                                                    Wobei, es wäre möglich den zu verwenden wenn defaultmässig die Suche nur auf komplette Worte geht und Prä- und Postfixsuchen beide über den Teilwortindex realisiert werden.

                                                                    Gruss Daniela

                                                              2. Hi Christian,

                                                                Wie PostGreSQL doppelte Eintraege verwaltet, kann ich dir
                                                                leider nicht sagen. Ich koennte mir vorstellen, dass es in
                                                                jedem Hash-Element eine lin. Liste gibt.

                                                                hm ... kommt wohl darauf an, wie groß der Schlüsselraum im Vergleich zu den zu speichernden Werten ist. Wenn es möglich und sogar wahrscheinlich ist, daß viele Werte denselben Hashcode haben, dann kann eine lineare Liste langsam sein. Natürlich möchte man dann den Hash-Key gerne länger machen ... aber wird damit die entsprechende Speichertabelle nicht explosionsartig größer?

                                                                Ich könnte mir zumindest vorstellen, in bestimmten Fällen eine Hybrid-Technik einzusetzen, d. h. spätestens beim Erreichen der maximalen erwünschten Hash-Schlüssellänge die dann immer noch vorhandenen mehrdeutigen Werte nicht in Listen, sondern in sortierten Bäumen zu speichern (meinetwegen erst ab einer Mindest-Anzahl Einträge pro Hash-Key, dann müßte man nicht zwischendurch schlagartig die gesamte Tabelle anpassen, und wenn der Treiber schon schlau sein muß, dann kann er auch gleich dynamisch schlau sein).

                                                                Viele Grüße
                                                                      Michael

                                                                --
                                                                T'Pol: I meant no insult.
                                                                V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                                1. Hallo Michael,

                                                                  Wie PostGreSQL doppelte Eintraege verwaltet, kann ich
                                                                  dir leider nicht sagen. Ich koennte mir vorstellen,
                                                                  dass es in jedem Hash-Element eine lin. Liste gibt.

                                                                  hm ... kommt wohl darauf an, wie groß der Schlüsselraum im
                                                                  Vergleich zu den zu speichernden Werten ist. Wenn es
                                                                  möglich und sogar wahrscheinlich ist, daß viele Werte
                                                                  denselben Hashcode haben,

                                                                  Moment. Doppelte Eintraege heisst, Eintraege zu haben, die
                                                                  denselben Key (nicht dieselbe Hash-Summe!) haben, aber doch
                                                                  unterschiedlich sind. Ein Hash-Index ist ja nicht
                                                                  zwangslaeufig unique.

                                                                  dann kann eine lineare Liste langsam sein. Natürlich
                                                                  möchte man dann den Hash-Key gerne länger machen ...

                                                                  Tatsaechlich wuerde ich persoenlich zwei Sachen machen: ab
                                                                  einer bestimmten Anzahl von Dupletten (Eintraege mit
                                                                  verschiedenen Keys aber denselben Hash-Summen!) die Tabelle
                                                                  vergroessern, aber ansonsten einen Suchbaum benutzen. IMHO
                                                                  weiss die DB genug ueber die Schluessel, um ein derart
                                                                  eigenmaechtiges Handlen zu rechtfertigen.

                                                                  aber wird damit die entsprechende Speichertabelle nicht
                                                                  explosionsartig größer?

                                                                  Ja. Im Normalfall wird um eine Zweierpotenz vergroessert, weil
                                                                  die gaengigen Hash-Funktionen sonst Modulo brauchen. Und das
                                                                  ist sehr, sehr langsam (im Vergleich zum Rest der
                                                                  Hash-Funktion).

                                                                  Gruesse,
                                                                   CK

                                              2. Hi Christian,

                                                Das heisst, dass *nicht* der komplette Index im Speicher
                                                gehalten wird, sondern nur teilweise im Speicher behalten
                                                werden braucht.

                                                das macht Perl mit seinem Hash vielleicht auch, aber
                                                Nein, Perl haelt alle Hashes komplett im Speicher. Wenn etwas
                                                auf die HD ausgelagert wird, dann wird das vom OS gemacht
                                                (Swapping), aber nicht von Perl.

                                                Du mußt die Daten bei der Perl-Lösung
                                                wenigstens einmal komplett "durch den Speicher
                                                schießen", bevor sie in der paging area landen.
                                                Was meinst du mit dem oberen Satz, Michael?

                                                Wenn ich (in meiner Inkarnation als Perl-Laufzeitsystem) eine Datenstruktur wie z. B. einen Hash in den Hauptspeicher laden will, welche dort nicht hinein paßt, dies aber dadurch tun muß, daß ich deren Speicherabbild von der Festplatte lese, dann habe ich alle Teile des Hash (nacheinander) mindestens einmal im Hauptspeicher, bevor diese Operation fertig ist. Für den Platz, welcher von den letzten gelesenen Teilen belegt wird, müssen dann früher gelesene Teile des Hashes ausgelagert werden ... und ich habe am Ende wahrscheinlich sogar nur die Blätter im RAM und die inneren Knoten raus geswappt, also genau das Gegenteil dessen, was ich eigentlich will.

                                                Navigiere ich (in meiner Inkarnation als Datenbanktreiber) aber innerhalb eines Indexbaums, dann lese ich tatsächlich nur die benötigten Speicherseiten ein - und ich bin mir 'bewußt', daß innere und äußere Baumknoten unterschiedliche Qualitäten haben, also nicht 'gegeneinander' swappen sollten. Ich kann dann verschiedene Teile desselben Indexbaums unterschiedlich priorisieren bezüglich ihrer Verfügbarkeit im Hauptspeicher.

                                                Viele Grüße
                                                      Michael

                                                --
                                                T'Pol: I meant no insult.
                                                V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                1. Hallo Michael,

                                                  Wenn ich (in meiner Inkarnation als Perl-Laufzeitsystem)
                                                  eine Datenstruktur wie z. B. einen Hash in den
                                                  Hauptspeicher laden will, welche dort nicht hinein paßt,
                                                  dies aber dadurch tun muß, daß ich deren Speicherabbild
                                                  von der Festplatte lese, dann habe ich alle Teile des Hash
                                                  (nacheinander) mindestens einmal im Hauptspeicher, bevor
                                                  diese Operation fertig ist.

                                                  Korrekt.

                                                  Für den Platz, welcher von den letzten gelesenen Teilen
                                                  belegt wird, müssen dann früher gelesene Teile des Hashes
                                                  ausgelagert werden ...

                                                  Auch korrekt. Oder andere Programme werden geswappt -- je
                                                  nach dem, wie oft du die Teiles des Hashes anforderst.

                                                  Ich kann dann verschiedene Teile desselben Indexbaums
                                                  unterschiedlich priorisieren bezüglich ihrer Verfügbarkeit
                                                  im Hauptspeicher.

                                                  Was du aber nicht kannst, ist das Swapping beeinflussen. Wenn
                                                  das Betriebssystem sagt 'ne, du, ich brauch jetzt Speicher,
                                                  du gehst ab in den Swap', dann tust du das auch. Diesen
                                                  Gesetzmaessigkeiten unterliegt *auch* eine DB. Sie kann also
                                                  uU gar nicht beeinflussen, ob nun die Knoten oder die
                                                  Blaetter geswappt werden oder nicht.

                                                  Gruesse,
                                                   CK

                                                  1. Hi Christian,

                                                    Was du aber nicht kannst, ist das Swapping beeinflussen. Wenn
                                                    das Betriebssystem sagt 'ne, du, ich brauch jetzt Speicher,
                                                    du gehst ab in den Swap', dann tust du das auch. Diesen
                                                    Gesetzmaessigkeiten unterliegt *auch* eine DB. Sie kann also
                                                    uU gar nicht beeinflussen, ob nun die Knoten oder die
                                                    Blaetter geswappt werden oder nicht.

                                                    wenn eine Datenbank beim Ladezeitpunkt einen bestimmten Pool an Speicher fest alloziert und diesen dem Swap-Mechanismus permanent entzieht, dann ist es ihr Job, den zu verwalten. Und sie kann dann beispielsweise Indexseiten dort hinein legen, während sie Datenseiten dem normalen Swapping-Mechanismus unterwirft.
                                                    Es hat schon seine Gründe, warum beispielsweise eine Oracle-Datenbank bei ihrer Installation den UNIX-Kernel modifiziert ... (bei Oracle 7 unter AIX 3 habe ich das selbst erlebt)

                                                    Viele Grüße
                                                          Michael

                                                    --
                                                    T'Pol: I meant no insult.
                                                    V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                    1. Hallo Michael,

                                                      wenn eine Datenbank beim Ladezeitpunkt einen bestimmten
                                                      Pool an Speicher fest alloziert und diesen dem
                                                      Swap-Mechanismus permanent entzieht, dann ist es ihr Job,
                                                      den zu verwalten.

                                                      Wie sollte sie den Speicher dem Swapping-Mechanismus
                                                      entziehen? Das *kann* sie nicht. Danach wird sie nicht
                                                      gefragt. Eine DB arbeitet genau so mit Systemcalls wie ein
                                                      beliebiges anderes Programm.

                                                      Es hat schon seine Gründe, warum beispielsweise eine
                                                      Oracle-Datenbank bei ihrer Installation den UNIX-Kernel
                                                      modifiziert ... (bei Oracle 7 unter AIX 3 habe ich das
                                                      selbst erlebt)

                                                      Klar hat das seine Gruende -- aber meist andere :))

                                                      Gruesse,
                                                       CK

                                                      1. Hi Christian,

                                                        wenn eine Datenbank beim Ladezeitpunkt einen bestimmten
                                                        Pool an Speicher fest alloziert und diesen dem
                                                        Swap-Mechanismus permanent entzieht, dann ist es ihr Job,
                                                        den zu verwalten.
                                                        Wie sollte sie den Speicher dem Swapping-Mechanismus
                                                        entziehen? Das *kann* sie nicht. Danach wird sie nicht
                                                        gefragt. Eine DB arbeitet genau so mit Systemcalls wie ein
                                                        beliebiges anderes Programm.

                                                        letzteres ist m. E. keine feststehende Tatsache, sondern nur eine Möglichkeit. Für Dich ist eine Datenbank ein normales Anwendungsprogramm - ich kann sie mir aber sehr gut auch als privilegierten Gerätetreiber vorstellen.
                                                        Es gibt Kernel-Routinen, die viel zu wichtig sind, als daß man deren Code dem Swapping unterwirft, weil sie ständig gebraucht werden (beispielsweise die Routinen, die das Swapping durchführen ;-). Wenn also diese Routinen in einem nicht-swappable-Bereich des RAM liegen, scheint der Kernel dies grundsätzlich zu beherrschen.
                                                        Dann jedoch kann man den Kernel auch so modifizieren, daß sich die Datenbank ebenfalls einen Teil non-swappable RAM nehmen darf ... der ist dann halt 'weg', und das Betriebssystem muß mit dem Rest auskommen. Deshalb sollte man diesen Teil normalerweise nicht zu groß dimensionieren.

                                                        Viele Grüße
                                                              Michael

                                                        --
                                                        T'Pol: I meant no insult.
                                                        V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                        1. Hallo Michael,

                                                          letzteres ist m. E. keine feststehende Tatsache, sondern
                                                          nur eine Möglichkeit.

                                                          Eigentlich nicht.
                                                          Das OS muss dafuer sorgen, dass immer genuegend Speicher fuer
                                                          alle Programme zur Verfuegung steht. Und deshalb *muss* es
                                                          swappen.

                                                          Für Dich ist eine Datenbank ein normales
                                                          Anwendungsprogramm - ich kann sie mir aber sehr gut auch
                                                          als privilegierten Gerätetreiber vorstellen.

                                                          Sind sie aber nicht :) Weder DB2, noch PostGreSQL, noch
                                                          MySQL.

                                                          Es gibt Kernel-Routinen, die viel zu wichtig sind, als daß
                                                          man deren Code dem Swapping unterwirft, weil sie ständig
                                                          gebraucht werden (beispielsweise die Routinen, die das
                                                          Swapping durchführen ;-). Wenn also diese Routinen in
                                                          einem nicht-swappable-Bereich des RAM liegen, scheint der
                                                          Kernel dies grundsätzlich zu beherrschen.

                                                          Das haengt aber nicht am RAM-Bereich, sondern an dem, der den
                                                          Code ausfuehrt.

                                                          Nein, sowohl PostGreSQL als auch MySQL als auch DB2
                                                          unterliegen ganz normal dem Swapping. Und es wuerde mich sehr
                                                          wundern, wenn das bei Oracle anders waere.

                                                          Gruesse,
                                                           CK

                                                          1. Hi Christian,

                                                            Das OS muss dafuer sorgen, dass immer genuegend Speicher fuer
                                                            alle Programme zur Verfuegung steht. Und deshalb *muss* es
                                                            swappen.

                                                            das habe ich nicht in Frage gestellt - ich kann mir nur unterschiedlich große "Zuständigkeitsbereiche" für diese Funktion vorstellen.

                                                            Swapping durchführen ;-). Wenn also diese Routinen in
                                                            einem nicht-swappable-Bereich des RAM liegen, scheint der
                                                            Kernel dies grundsätzlich zu beherrschen.
                                                            Das haengt aber nicht am RAM-Bereich, sondern an dem, der den
                                                            Code ausfuehrt.

                                                            Deshalb hatte ich "Gerätetreiber" als Vorschlag gemacht: Die Datenbank - oder zumindest der Verwalter dieses Memory-Pools - müßte dann ein Kernel-Prozeß sein, ja.

                                                            Nein, sowohl PostGreSQL als auch MySQL als auch DB2
                                                            unterliegen ganz normal dem Swapping. Und es wuerde mich sehr
                                                            wundern, wenn das bei Oracle anders waere.

                                                            Mich würde wundern, wenn bei wirklich wichtigen Anwendungen noch niemand auf die Idee gekommen wäre, die Datenbank gegenüber den restlichen Prozessen (shell, Webserver etc.) in dieser Hinsicht zu bevorzugen. Es gibt durchaus Anwendungsfälle, bei denen die Zugriffsgeschwindigkeit auf bestimmte Daten wichtig genug sein sollte, daß diese Daten "Kernel-Charakter" haben ...

                                                            Wie ist das eigentlich mit shared memory pools, werden die auch geswapped?

                                                            Viele Grüße
                                                                  Michael

                                                            --
                                                            T'Pol: I meant no insult.
                                                            V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                            1. Hallo Michael,

                                                              [... Swapping *muss* geschehen ...]

                                                              das habe ich nicht in Frage gestellt

                                                              Ich habe es nur noch einmal zur Erklaerung geschrieben :)

                                                              Deshalb hatte ich "Gerätetreiber" als Vorschlag gemacht:
                                                              Die Datenbank - oder zumindest der Verwalter dieses
                                                              Memory-Pools - müßte dann ein Kernel-Prozeß sein, ja.

                                                              Ich kann mir nicht vorstellen, dass jemand das einsetzen
                                                              wuerde. Ich zumindest wuerde das nicht. Das ist eine
                                                              Sicherheitsluecke^3.

                                                              Nein, sowohl PostGreSQL als auch MySQL als auch DB2
                                                              unterliegen ganz normal dem Swapping. Und es wuerde
                                                              mich sehr wundern, wenn das bei Oracle anders waere.

                                                              Mich würde wundern, wenn bei wirklich wichtigen
                                                              Anwendungen noch niemand auf die Idee gekommen wäre, die
                                                              Datenbank gegenüber den restlichen Prozessen (shell,
                                                              Webserver etc.) in dieser Hinsicht zu bevorzugen.

                                                              Oh, das ist keine Frage. Das geschieht mit Sicherheit (ueber
                                                              Prozess-Prioritaeten, etc). Aber sie unterliegen trotzdem den
                                                              Swapping-Technologien.

                                                              Wie ist das eigentlich mit shared memory pools, werden die
                                                              auch geswapped?

                                                              Das kann ich dir nicht mit Sicherheit sagen. Aber ich kann
                                                              es mir durchaus vorstellen, ja.

                                                              Gruesse,
                                                               CK

                                                              1. Hallo Michael,

                                                                so, ich habe nochmal nachgeforscht: es gibt die Moeglichkeit,
                                                                nicht-swapbaren Speicher anzufordern, mit kmalloc() bzw.
                                                                vmalloc(). Ich weiss aber nicht, wie portabel das ist, in der
                                                                Standard-C-Lib ist es nicht definiert. Und bei meinem
                                                                FreeBSD-System gibt es lediglich kmalloc(). Ausserdem gibt es
                                                                einige Einschraenkungen: man kann nur Page-Weise speicher
                                                                anfordern und der Prozess wird entweder solange suspended, bis
                                                                genuegend Speicher frei ist, oder es wird einfach soviel
                                                                Speicher reserviert, wie gerade frei ist.

                                                                Gruesse,
                                                                 CK

                                                                1. Hi Christian,

                                                                  so, ich habe nochmal nachgeforscht: es gibt die Moeglichkeit,
                                                                  nicht-swapbaren Speicher anzufordern, mit kmalloc() bzw. vmalloc().

                                                                  <grin size="dr.phlox" />

                                                                  Ausserdem gibt es einige Einschraenkungen: man kann nur Page-Weise speicher
                                                                  anfordern und der Prozess wird entweder solange suspended, bis genuegend
                                                                  Speicher frei ist, oder es wird einfach soviel Speicher reserviert, wie
                                                                  gerade frei ist.

                                                                  So etwas müßte einem RBDMS beim daemon-Start zuzumuten sein, denke ich - das ist die Sache wert.

                                                                  Viele Grüße
                                                                        Michael

                                                                  --
                                                                  T'Pol: I meant no insult.
                                                                  V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                                  1. Hallo Michael,

                                                                    Ausserdem gibt es einige Einschraenkungen: man kann nur
                                                                    Page-Weise speicher anfordern und der Prozess wird
                                                                    entweder solange suspended, bis genuegend Speicher frei
                                                                    ist, oder es wird einfach soviel Speicher reserviert, wie
                                                                    gerade frei ist.

                                                                    So etwas müßte einem RBDMS beim daemon-Start zuzumuten sein,
                                                                    denke ich - das ist die Sache wert.

                                                                    Ansichtssache. Und tatsaechlich machen das weder MySQL noch
                                                                    PostGreSQL :) Und, wie gesagt, es waere mir nicht bekannt,
                                                                    dass diese Funktion standardtisiert ist. Auf meinem FreeBSD
                                                                    sieht der Funktions-Prototyp ganz anders aus als auf meinem
                                                                    Linux (Kernel 2.4.12 oder so).

                                                                    Mal ganz abgesehen davon steht ueberigens ausdruecklich dabei,
                                                                    man solle diese Funktion meiden. Nicht-Swapbarer Speicher ist
                                                                    absolut abzuraten, da kritisch.

                                                                    Gruesse,
                                                                     CK

                                                                    1. Hi Christian,

                                                                      Mal ganz abgesehen davon steht ueberigens ausdruecklich dabei,
                                                                      man solle diese Funktion meiden. Nicht-Swapbarer Speicher ist
                                                                      absolut abzuraten, da kritisch.

                                                                      Ich würde auch keinem DAU raten, so etwas hemmungslos einzusetzen. Aber ich lebe in einer Welt der Spezialmaschinen ... ich möchte sehr wohl einen einzigen Prozeß gegenüber allen anderen Prozessen so priorisieren können, weil ich realtime-Daten zeitnah verarbeiten muß und ähnliches Zeug. (Einige dieser Maschinen arbeiten mit einer von unserer Mutterfirma geschriebenen Hauptspeicherdatenbank.)
                                                                      Sag mir bitte nicht, daß UNIX für solche Aufgaben nicht das geeignete Betriebssystem sei ...

                                                                      Viele Grüße
                                                                            Michael

                                                                      --
                                                                      T'Pol: I meant no insult.
                                                                      V'Lar: Of course not. You're simply speaking your mind ... as you always have.
                                                                      1. Hallo Michael,

                                                                        Ich würde auch keinem DAU raten, so etwas hemmungslos
                                                                        einzusetzen. Aber ich lebe in einer Welt der
                                                                        Spezialmaschinen ... ich möchte sehr wohl einen einzigen
                                                                        Prozeß gegenüber allen anderen Prozessen so priorisieren
                                                                        können, weil ich realtime-Daten zeitnah verarbeiten muß und
                                                                        ähnliches Zeug.

                                                                        Die Moeglichkeiten sind dir auch durchaus gegeben: durch
                                                                        Prozess-Prioritaeten und Ressourcen-Limits. Aber wenn du mit
                                                                        Nicht-Swapbarem Speicher 'rumspielst, forderst du einen
                                                                        System-Absturz geradezu hinaus.

                                                                        Sag mir bitte nicht, daß UNIX für solche Aufgaben nicht
                                                                        das geeignete Betriebssystem sei ...

                                                                        Ich werde mich hueten! Da ist ein Unix genau die richtige
                                                                        Wahl.

                                                                        Gruesse,
                                                                         CK

                              3. Hi Michael,

                                stimmt, die Tipps&Tricks sind noch gar nicht drin. Ich setz es mal auf meine Wunschliste, es ist ja bald Weihnachten.....

                                Viele Grüße
                                Mathias Bigge

                    2. Hi Lude,

                      Die Faq hat natürlich verschiedene Funktionen und wird dementsprechend auch verschieden genutzt. Z.B. kann man auf bestimmte Standardlösungen verlinken, oder selber danach suchen...

                      Die Qualität der Forumsbeiträge, und darum scheint es zu gehen, hängt immer nur _auch_ von den Forumsregeln ab. Die Wirklichkeit entscheidet in diesem komplexen System was an Beiträgen "hochkommt".

                      Ja, das Forum selbst muss immer wieder neu eine Art von Qualitätskontrolle ausüben. Aber da es uns wichtig ist, dass ein bestimmtes Vorwissen vorausgesetzt wird, auch, damit die Diskussionen für uns interessant bleiben, ist es schön, wenn es einen Ort gibt, an dem man, vielleicht nicht gleich, aber spätestens, wenn man aneckt, die Standards finden kann.

                      Rein formale Argumentation, welche in 100% lenkbaren Systemen greift. - Was ist schon absurd?   :-)
                      Und das wäre vielleicht etwas für Psychologen und Soziologen, weniger für rechtwinklige Denker.

                      1. It's hip to be a square.
                      2. Du neigst zu Sprüngen auf die Metaebene, die vorsichtig gesagt, ein wenig klugscheißerisch sind ;-)
                      Viele Grüße
                      Mathias Bigge

                      1. Hi, Du Komiker!

                        Rein formale Argumentation, welche in 100% lenkbaren Systemen greift. - Was ist schon absurd?   :-)
                        Und das wäre vielleicht etwas für Psychologen und Soziologen, weniger für rechtwinklige Denker.

                        1. It's hip to be a square.

                        :-)

                        1. Du neigst zu Sprüngen auf die Metaebene, die vorsichtig gesagt, ein wenig klugscheißerisch sind ;-)

                        Also, wenn diskutiert wird, welchen Sinn Regeln im Forum machen, darf doch gefragt werden, was Regeln grundsätzlich zu leisten imstande sind hier.

                        Ich weiss nicht, was Du mit dem merkwürdigen Wort "klugscheisserisch" genau meinst, aber arrogant bin ich anerkanntermassen nicht. - Vielleicht etwas aggressiv; aber sicherlich nur, weil ich hier unerkannt bin.

                        Viele Grüße
                        Mathias Bigge

                        Gruss,
                        Lude

              2. Hallo, Chräcker,

                andererseits gibt es aber auch immer wieder neue Wunschlisten,
                welche Standardlösung noch in die FAQ sollte, um das Forum zu
                entlasten.

                ...eine FAQ beduetet ja nicht, so wie sie bisher zum teil aufgebaut ist, daß dort Fragen beantwortet werden, die sich ein Besucher hier "mal besser stellen sollte"

                Gerade den Aspekt der FAQ, dass sie eigentlich keine FAQ ist, gefällt mir. Sie ist eine Metaanleitung, sie hält einige grundlegende Überlegungen über die Art und Weise des Diskutierens fest. Sie stellt eine Art Charta dar, in welcher der "Ethos" des Selfforums artikuliert ist. (Sicherlich, vieles lässt sich nicht sprachlich als Regel formulieren, es entsteht und schafft sich im direkten Umgang, "Ethos" hat sicherlich einen zu hohen Anspruch.)
                Der Name "FAQ" sagt lediglich etwas über die Struktur aus, in welcher die Inhalte angeordnet sind, nämlich indem (auch) fiktive Fragen beantwortet werden. Diese Gliederung finde ich, abgesehen davon, dass es nicht die tatsächlichen "frequently asked questions" des Forums sind, sehr hilfreich und benutzerfreundlich.

                sondern eben wirklich, daß Fragen beantwortet werden, *die* (sich) Besucher stellen

                Welche denn? Rein technische? Auch diese werden in der jetzigen FAQ beantwortet, weiterhin gibt es http://selfhtml.teamone.de/navigation/faq.htm#liste und die allerbeste Antwortmaschine ist nach Selfhtml selbst (inklusive Tipps&Tricks und Feature-Artikel usw.) mit Sicherheit das Archiv...

                Also Fragen wie "warum darf ich nicht eine frage in 5 Minuten Intervallen wiederholen" fragt sich ja niemand.

                Nein, aber es ist nunmal eine Regel, die von vielen stillschweigend akzeptiert wird, weil sie es als selbstverständlich ansehen. Dennoch scheint es vielen nicht bewusst zu sein, da es sehr oft vorkommt, deshalb ist es nötig, denjenigen darauf aufmerksam zu machen, dass man mit seinem Verhalten nicht einverstanden ist (was nicht bedeutet, dass man einen FAQ-Link mit dem Hinweis setzt "die Regeln sind so, halte dich gefälligst daran", das ist meiner bescheidenen antipädagogischen Meinung nach nicht förderlich).

                Beispielsweise kommt es täglich unzählige Male vor, dass jemand eine Frage schlecht stellt, sodass man (zumindest ich ;)) demjenigen helfen möchte, es aber nicht kann, weil man die Frage derart wenig versteht, dass man im Grunde nichts anderes als eine "Was willst du eigentlich wissen"-Messagerafik als Antwort posten könnte. Des weiteren rotzen einige ihre Fragen ins Forum, ohne sich Selfhtml angeschaut zu haben beziehungsweise anderweitig selbst nach einer Lösung gesucht zu haben, das dürfte bekannt sein.
                Niemand, auch nicht ich, hat Lust, täglich diesen dutzenden Fragestellern von neuem zu erklären, wie Fragen so gestellt werden, dass die anderen Forumsteilnehmer überhaupt helfen können und dass Freundlichkeit und Eigeninitiative dazu führen, dass man auch respektvoll und freundlich behandelt wird. Diese immer wiederkehrenden (frequently) Metadiskussionen, in welchen jedem "Newbie" speziell beigebracht wird, wie die Allgemeinheit hier miteinander umgeht, wie das Forum funktioniert etc., gehören meiner Meinung nach nicht in das Forum beziehungsweise sollten vermieden werden, weil es ein Treffpunkt für Netzautoren darstellt und sich nicht damit beschäftigt, Neubenutzer in die (grundlegende) Benutzung des Forums einzuleiten (der Rest ergibt sich meist von selbst, "learning by doing", ich will beileibe nicht, dass sich jemand "zügelt" und wie ein braver Forumsteilnehmer funktioniert). Was ist falsch daran, den Benutzer kurz auf die FAQ aufmerksam zu machen, anstatt ihm eine individuellöe Einführung zu geben, welche man schon dutzendmal geschrieben hat und quasi aus der Zwischenablage herausrutschen lassen könnte, weil sie so beliebig ist. "Du, dazu gibt es einen Punkt in der FAQ, da steht, wie du am besten Deine Frage formuliert, um passende Antworten zu erhalten, vielleicht hilft dir das" ist natürlich denkbar geeigneter als "Lies die </faq/>!".
                Die FAQ kann genauso eine kleine Anleitung sein, welche den Fragesteller an die Hand nimmt und ihm Fragen liefert, die er sich stellen sollte (wobei tritt das Problem auf, wurden Versuche unternommen, das Problem zu lokalisieren, welche Lösungsmöglichkeiten wurden schon geprüft, kurz gesagt wo *genau* liegt der Fehler et cetera), Hilfe zur SELFhilfe sozusagen *g*.

                Ich persönlich gebe solche Einführungen lieber zum xten Mal als dass ich die FAQ verlinke, dieses mörderisch große Dokument wird jeden abschrecken, wenn er mitten hineingerät, da stimme ich dir zu... Dennoch kann ich absolut verstehen, dass viele Stammposter nach tausenden Diskussionen keine Motivation mehr haben, jeden "Newbie" einzeln zu unterrichten, wie man selbst Probleme löst...

                Die, die es wissen, machen es nicht, die anderen sind eh zu deppert um auf diese Frage zu kommen.

                Wenn du dieser Ansicht bist, fändest du es womöglich auch generell unmöglich, Regeln zu definieren und andere zu zwingen, sich an der hier gepflegten Diskussionskultur zu orientieren.
                Leider kann man mit Leute, die "eh zu deppert" sind, nicht rechnen (nicht leben). Ich glaube auch eigentlich nicht, dass du es so meintest, schließlich möchtest du auch alles andere, als dass die "Errungenschaften" (hust, arges Wort, zugegeben ;)) des Forums nicht aufgegeben werden und es zu einer "Antwortmaschine" verkommt, welche mundgerechte Lösungen auf Zuruf anbietet.

                Eine echte FAQ wäre also in der tat eine liste von fragen, die hier "exakt" so immer wieder gestellt wird. Diese Listungen gibts ja aber in der Tips-und-Tricks Sektion, zum teil in der Spezial-beitrag-Sektion und wie die Ecken alle lauten, die sich so langsam hier im seöf-Raum angesammelt haben.

                Ja. Aber was tut man dagegen, dass niemand diese Fülle von Informationen nutzt? Die Masse an Wissen mag verwirrend sein, aber so oder so ist die Einarbeitungszeit nicht überspringbar, ich habe Jahre gebraucht, um mich im Selfraum einigermaßen zurechtzufinden und zu wissen, wo ich suchen muss, dazu gehört auch die Kunst, aus Suchergebnissen auf einen Blick hilfreiche Treffer herauszusehen (erst einmal muss man natürlich die Selfsuche kennen *fg*), oder überhaupt die Fähigkeit, ein Problem strukturiert anzugehen und zu erörtern...

                Für mich könnte fast die ganze FAQ weg bzw umverteilt werden.

                "Wo Leute über einen längeren Zeitraum hinweg diskutieren, wie im SELFHTML Forum, entstehen erwünschte Verhaltensregeln, und es gibt Dinge, die Stammbesucher des Forums nicht jedem Neuling wieder von vorne erklären wollen. Deshalb gibt es die Forums-FAQ."
                Wieso findest du das nicht wichtig beziehungsweise lehnst eine solche Sammlung grundsätzlich ab? Unabhängig davon, ob jeder Neubenutzer die FAQ Eintrag für Eintrag abarbeitet (das ist eine Sache der Barrieren für Unerfahrene, welche abgebaut werden sollten), finde ich es wichtig, dass diese Regeln überhaupt irgendwo notiert sind, es geht auch um eine Benutzungsanleitung für das Forum. Alles das ist *nicht* jedem geläufig oder selbstverständlich und nur weil es in dieser Form wenig Beachtung findet - obwohl es meine Meinung nach nicht in dem Maße schlecht gegliedert ist wie deine Aussagen vermuten lassen würden - würde ich nicht die Notwendigkeit bezweifeln.

                Im strengsten Sinne ist das ganze selfhtml eine FAQ....

                ...die oft auch nicht öfters gelesen wird als die Forums-FAQ.

                Grüße,
                Mathias

                --
                Remember: KING KONG Died For Your Sins!
                "Wie ein gefoppter Nachtmahr der auf Tücke sinnt..." (Hugo Ball, "Die Katze")
                1. Hallo,

                  Sie stellt eine Art Charta dar, in welcher der "Ethos" des
                  Selfforums artikuliert ist.

                  Ja. Als solches mag sie mir ja auch gefallen. Sie kann aber in den meisten Fällen dann nur "rückwärts" angewendet werden, um Leute bei einem "Ethikverstoß" ,-) darauf aufmerksam zu machen, daß dies kein regelfreier Raum ist.

                  (...) deshalb ist es nötig, denjenigen darauf aufmerksam zu machen,
                  dass man mit seinem Verhalten nicht einverstanden ist (was nicht
                  bedeutet, dass man einen FAQ-Link mit dem Hinweis setzt "die Regeln
                  sind so, halte dich gefälligst daran", das ist meiner bescheidenen
                  antipädagogischen Meinung nach nicht förderlich).

                  "Eben"....

                  Ich persönlich gebe solche Einführungen lieber zum xten Mal als
                  dass ich die FAQ verlinke, dieses mörderisch große Dokument wird
                  jeden abschrecken, wenn er mitten hineingerät, da stimme ich dir
                  zu... Dennoch kann ich absolut verstehen, dass viele Stammposter
                  nach tausenden Diskussionen keine Motivation mehr haben, jeden
                  "Newbie" einzeln zu unterrichten, wie man selbst Probleme löst...

                  Ja. Als solches habe ich ja die FAQ auch schon verstanden, eben als Hinweis-Archiv. Halte ich auch für legitim, wer wie schreibt sollte ja wirklich individuell bleiben, mir würde ja die knackigkeit mancher tatsächlich fehlen.

                  Wenn du dieser Ansicht bist, fändest du es womöglich auch generell
                  unmöglich, Regeln zu definieren und andere zu zwingen, sich an der
                  hier gepflegten Diskussionskultur zu orientieren.

                  Nein nein. Im Gegenteil. Ich denke einfach (blauäuig) es würde die Regel "benimm Dich anständig" reichen. Und, schon ernsthaft, die meisten "Verstöße" wie mehrmaliges "nachposten" oder "fertig-Script-einfordern" werden schon in einem gewissen "Dreistigkeitsbewustsein" begangen.... glaube ich ,-) - und denen sind dann ausformuliertere Regeln auch leider egal. (Da wünschte ich mir immer mehr "Exekutive", aber das verate ich nur heimlich.... (fehlt ja auch an Umsetzungsideen meinerseits, und nein, ich will keine neue Forumshenker, wie wir sie ja mal hatten....)

                  Ja. Aber was tut man dagegen, dass niemand diese Fülle von
                  Informationen nutzt?

                  Häufiger sich auf die Finger hauen, wenn man eine zu ausführliche Antwort geben möchte ;-)

                  ich habe Jahre gebraucht, um mich im Selfraum einigermaßen
                  zurechtzufinden und zu wissen, wo ich suchen muss,

                  oh ja. ich glaube aber auch, daß "wir" erfahreneren schon an der Frage herauslesen können, ob da jetzt nur jemand ein Brett vor den Augen hatte oder gar nicht erst gesucht hat. Da mag man auch mal falsch liegen, aber dafür kann man sich ja immer noch entschuldigen. (Eine Möglichkeit, die dann vielleicht auch mal in der FAQ vermerkt werden könnte ;-)

                  Wieso findest du das nicht wichtig beziehungsweise lehnst eine
                  solche Sammlung grundsätzlich ab?

                  naja, weil ich selber da erst vor ein paar Monaten das erste mal reingeschaut habe? ;-) Aber nein nein, ich poltere zwar gerne, aber komplett lehne ich sie ja nicht ab. Mir kommt sie eben "atmospährisch" immer etwas lang vor. Sie hat etwa so viele Wörter, wie die ersten 82 Abschnitte der FAQ unseres Landes.

                  In diesem Sinne war auch diese Diskussion ein Beitrag, um mein "Gefühl" etwas zu relativieren.

                  Chräcker

                  1. Rehi,

                    Wieso findest du das nicht wichtig beziehungsweise lehnst eine
                    solche Sammlung grundsätzlich ab?
                    naja, weil ich selber da erst vor ein paar Monaten das erste mal reingeschaut habe? ;-) Aber nein nein, ich poltere zwar gerne, aber komplett lehne ich sie ja nicht ab. Mir kommt sie eben "atmospährisch" immer etwas lang vor. Sie hat etwa so viele Wörter, wie die ersten 82 Abschnitte der FAQ unseres Landes.

                    In diesem Sinne war auch diese Diskussion ein Beitrag, um mein "Gefühl" etwas zu relativieren.

                    nu ja, meins ist nicht relativiert, ich kann mich noch entsinnen, das ich
                    vor etwa 1 1/2 jahren hier in den FAQ einfach einen hilfreichen hinweis
                    unter den meistgestellten Fragen gefunden habe.
                    Vor einem Monat (oder so?) war ich ausserstande dieses ding auf die schnelle
                    wiederzufinden.
                    FAQ heisst ja an sich schon Frequently Asked Questions, und da gehört
                     meiner meinung nach nicht (in form einer Fragestellung )rein wie man
                    sich benehmen soll. das gehört in eine extra sparte wie verhaltensregeln
                    oder so. na ja, aber dann kann man auch wieder sagen das man irgendwann
                    vor lauter links nicht mehr durchblickt. ich würde es auf jeden fall so
                    besser finden.

                    gruß

                    sonia

  6. hi

    mir ist aufgefallen, das einige Forum-User in letzter Zeiter sehr gereitzt auf Postings von Neulingen reagieren. Sicherlich kommt es vor, das einige Fragen zu x-ten mal gestellt werden.
    Ist das denn ein Grund gleich so aus der Haut zu fahren?

    ich denke, das das eher so langsam aber sicher Regignation vor der scheinbar unendliche Dummheit oder Naivität "da draußen" ist. In diesem Forum gibt es ein paar Verhaltensweisen, die wir als selbstverständlich ansehen, wenn dann eben diese immer wieder angezweifelt werden, wird man schnell ungemütlich:
    -> Vertäge und Gesetze sind dazu da eingehalten zu werden. Somit würde der typische Self-User nie auf die Idee kommen zu fragen, wie man sich Freespace-Angebote erschleicht oder wie man kostenlos an Software kommt, die nicht als kostenlos gedacht ist.
    -> Standards sind dazu da, dass man sie einhält. Und Standards macht grundsätzlich nicht eine Firma alleine, sonst ist es keiner
    -> Respekt vor dem Seitenbesucher. Es steht hier für die meisten eben nicht im Vordergrund, sich auf eienr Website selbst darzustellen, oder zu zeigen, was man kann, sondern eine Information an möglichst viele Leute rüberzubringen und dabei darauf zu achten, dass diese gerne wiederkommen, dabei will man Dinge, die einen selbst nerven (weil sie ablenken) auch anderen nicht zumuten.
    -> Tolleranz gegenüber Minderheiten. Im Internet heisst das, das keine Gruppe zu unbedeutend ist, um eine Information bekommen zu dürfen. Somit muss so irgend möglich eben jeder browser bedient werden und nicht nur eine vermutete Mehrheit.
    -> Information != Präsentation. Auch ein Punkt, mit dem viele Stammposter sogar noch Probleme haben, es gibt eben gerade an einer Website dinge, bei denen es schön ist sie zu haben, aber wenn es nicht geht, fehlt eben nur dieses Detail und es wird nicht gleich der User ausgesperrt.
    -> formelle Regeln. Es ist nicht zu viel verlangt, wenn man ein Posting mit einer Anrede beginnt, URLs funktionsfähig gestaltet und auf übermäßige Verwendung von "!" und Grußschreibung verzichtet. Achja, ein Blick in die FAQ wirkt auch Wunder.
    ...so, wenn man diese 6 Punkte beachtet, sollte man hier keine Probleme bekommen - wenn doch, hatte wohl einer 'nen schlechten Tag.

    Grüße aus Bleckede

    Kai

    1. Hallo,

      bei allem respekt, wie es so schön heist, aber ein paar punkte, die Du nennts, halte ich schon für Diskussionswürdig und würde mir es auch verbeten, diese in einem nornalen Ton hier nicht mehr zur selbigen stellen zu dürfen. Pawlische Reflexe bei diesen Punkten halte auch ich abträglich für ein normales Miteinander.

      Die Einhaltung der von Dir genannte Punkte halte ich persönlich nicht für die Eintrittskarte zu einem gepflegten miteinander. (Vor allem, sorry, die für mich (!) unsinnige Gleichung "Information != Präsentation".

      (Tip: alle Leerzeilen in diesem Posting sollen die Präsentation dieser Information auf Deinem Bildschirm beeinflussen. Ich hoffe, die kommen an ,-))

      Chräcker

      --
      (hoffe, die Signatur wir auch so präsentiert, wie Du Dir es wünscht, um der Information weiter oben nicht zu stören ,-))
      http://www.Stempelgeheimnis.de
      1. hi

        Die Einhaltung der von Dir genannte Punkte halte ich persönlich nicht für die Eintrittskarte zu einem gepflegten miteinander. (Vor allem, sorry, die für mich (!) unsinnige Gleichung "Information != Präsentation".

        ich liebe diese Diskussion....
        Gemeint ist, das hier wohl miemand es als Aussperr-Grund für einen Browser akzeptiert, dass dieser keine transparenten Menüs hingekommt (warum auch immer).

        Grüße aus Bleckede

        Kai

    2. Hallo Kai,

      ich habe vermutlich nicht so viel Ahnung von sämtlichen Browsern und verstehe vom programmieren wahrscheinlich auch nicht so viel wie du, aber ich finde das deine Thesen nur teilweise stimmen. Sorry. Ich sehe es ein, dass man "gute" programmieren sollte und sich an Standarts haltens sollte, aber warum dann einen Anfänger nicht auch ein "Erfolgserlebnis" verspüren lassen. Ich denke das ich mich am Anfang auch nicht mit der Programmierung ausgekannt habe. Warum denn auch GoLive und Konsorten sind doch viel einfacher. Als ich dann hier fragen gestellt habe und mir Beiträge durchgelesen habe, ist mir aufgefallen, dass es auch noch andere Sachen gibt, als mal eben eine schöne Seite zusammmenklicken. Wenn jemand sofort niedergemacht wird, dann ist er entmutigt und kloppt irgendnen Blödsinn in die Tastatur und du hast Millionen von schlechten Sites, nur weil du (ich meine dich jetzt nicht nur direkt, beispiel) der Person ne Abfuhr erteilt hast. Man kann glücklicherweise aus Fehlern lernen. Aber geschimpfe bewirkt meistens Trotz.

      -> Vertäge und Gesetze sind dazu da eingehalten zu werden. Somit würde der typische Self-User nie auf die Idee kommen zu fragen, wie man sich Freespace-Angebote erschleicht oder wie man kostenlos an Software kommt, die nicht als kostenlos gedacht ist.

      Sehe ich 100% genauso... Regeln müssen eingehalten werden, aber man darf es auch nicht zu überbewerten...

      -> Standards sind dazu da, dass man sie einhält. Und Standards macht grundsätzlich nicht eine Firma alleine, sonst ist es keiner

      Ja genau, deshalb hast du ja auch weiter unten geschrieben, dass man für alle Browser (auch für die, die sich nicht an Standarts halten) seine Seiten programmieren sollte.

      -> Respekt vor dem Seitenbesucher. Es steht hier für die meisten eben nicht im Vordergrund, sich auf eienr Website selbst darzustellen, oder zu zeigen, was man kann, sondern eine Information an möglichst viele Leute rüberzubringen und dabei darauf zu achten, dass diese gerne wiederkommen, dabei will man Dinge, die einen selbst nerven (weil sie ablenken) auch anderen nicht zumuten.

      Stimmt, aber das ist für unsere Gesellschaft leider nicht mehr absolute Priorität. *leider*

      -> Tolleranz gegenüber Minderheiten. Im Internet heisst das, das keine Gruppe zu unbedeutend ist, um eine Information bekommen zu dürfen. Somit muss so irgend möglich eben jeder browser bedient werden und nicht nur eine vermutete Mehrheit.

      Hmm, ich sehe ein, dass beispielsweise für Sehbehinderte es sehr schwer Informationen zu bekommen. Falls du aber vermutete Mehrheit als Mircosoft siehst und die Minderheit als Mozilla, Opera usw., dann stimme ich dir nicht zu. Die haben auch Ihre macken und wenn die sich auch an Standarts halten würden gäb es weniger Probleme.

      -> Information != Präsentation. Auch ein Punkt, mit dem viele Stammposter sogar noch Probleme haben, es gibt eben gerade an einer Website dinge, bei denen es schön ist sie zu haben, aber wenn es nicht geht, fehlt eben nur dieses Detail und es wird nicht gleich der User ausgesperrt.

      Tja Information != Präsentation. Das ist doch blöde, sorry. Wenn ich wirkungsvoll Informiere, dann bleibt es nicht aus auch zu Präsentieren.

      -> formelle Regeln. Es ist nicht zu viel verlangt, wenn man ein Posting mit einer Anrede beginnt, URLs funktionsfähig gestaltet und auf übermäßige Verwendung von "!" und Grußschreibung verzichtet. Achja, ein Blick in die FAQ wirkt auch Wunder.

      Seh ich auch so, aber niemand der ein Frage hat, liest sich eine Seitenlange FAQ durch. Auch wenn ich dir bei den anderen Punkten zustimmte.

      Bis denne

      Daniel

      PS: Auch wenn ich deine Beiträge sonst schätze, muss ich doch sagen, dass ich diesmal etwas anderer Meinung bin.

      1. hi

        Hmm, ich sehe ein, dass beispielsweise für Sehbehinderte es sehr schwer Informationen zu bekommen. Falls du aber vermutete Mehrheit als Mircosoft siehst und die Minderheit als Mozilla, Opera usw., dann stimme ich dir nicht zu. Die haben auch Ihre macken und wenn die sich auch an Standarts halten würden gäb es weniger Probleme.

        nein, es ist genauso rassistisch, wenn man Leute nach ihrem, Browser, Betriebssystem oder Plugins aussperrt.

        Tja Information != Präsentation. Das ist doch blöde, sorry. Wenn ich wirkungsvoll Informiere, dann bleibt es nicht aus auch zu Präsentieren.

        es geht um die Leute, die auf einem einzelnen Effekt beharren, der nichts mit der Funktion der zeite zu tun hat - um nun ein Link einen Rollover-Effekt hat, ist z.B. scheißegal.

        Seh ich auch so, aber niemand der ein Frage hat, liest sich eine Seitenlange FAQ durch. Auch wenn ich dir bei den anderen Punkten zustimmte.

        ich denke, dass diese Regeln eigentlich selbstverständlich sein sollten (insbesondere die Grammatik), wenn nicht, ist im Elternhaus und/oder Schule irgendwas falsch gelaufen.

        Grüße aus Bleckede

        Kai

        1. Moin Moin,

          nein, es ist genauso rassistisch, wenn man Leute nach ihrem, Browser, Betriebssystem oder Plugins aussperrt.

          Warum? sehe ich nicht so. Warum sollte ich auf alles optische verzichten, wenn jemand das nicht anschauen kann? Ich kann ja nur ne Text Datei ins Netz stellen. Kann jeder lesen und enthält alle Informationen die man braucht. Warum macht man das nicht?

          Tja Information != Präsentation. Das ist doch blöde, sorry. Wenn ich wirkungsvoll Informiere, dann bleibt es nicht aus auch zu Präsentieren.
          es geht um die Leute, die auf einem einzelnen Effekt beharren, der nichts mit der Funktion der zeite zu tun hat - um nun ein Link einen Rollover-Effekt hat, ist z.B. scheißegal.

          Wenn es nur um Leute geht die einen Rollover-Effekt haben wollen, dann kann ich das auch verstehen, aber deshalb kann man doch nicht pauschal sagen Information != Präsentation. Wenn ich ne optisch ansprechende Seite habe, aber keinen Inhalt, dann ist das doof. Anderherum aber auch. Super Inhalt; scheiß Design... tja da bleibt dann auch viel auf der Strecke.

          ich denke, dass diese Regeln eigentlich selbstverständlich sein sollten (insbesondere die Grammatik), wenn nicht, ist im Elternhaus und/oder Schule irgendwas falsch gelaufen.

          Was meinst du jetzt? Welche Regeln sollten selbstverständlich sein? Die Begrüßung und Verabschiedung? Da gebe ich dir recht. Das sollte wirklich von klein auf gelernt werden. Aber der Rest?

          Tschöö

          1. hi

            Warum? sehe ich nicht so. Warum sollte ich auf alles optische verzichten, wenn jemand das nicht anschauen kann? Ich kann ja nur ne Text Datei ins Netz stellen. Kann jeder lesen und enthält alle Informationen die man braucht. Warum macht man das nicht?

            weil die Information immer noch da ist, wenn es nicht blinkt.

            Was meinst du jetzt? Welche Regeln sollten selbstverständlich sein? Die Begrüßung und Verabschiedung? Da gebe ich dir recht. Das sollte wirklich von klein auf gelernt werden. Aber der Rest?

            Das ein "!" nicht hinter jeden Satz gehört auch.

            Grüße aus Bleckede

            Kai

            1. Moin Moin,

              weil die Information immer noch da ist, wenn es nicht blinkt.

              Klar aber am Besten verkauft man doch mit noch einer optischen Unterstützung. Ich sehe ein, dass egal welches Design man hat der Inahlt gleich bleibt. Aber ich jeder Manager jeder Werbefachmann wird dir etwas anderes sagen. Das Auge ist mit? Warum wurde denn HTML erweitert CSS eingeführt, DHTML usw. Aus dem einfachen Grund, dass man etwas optische Buntes haben will. Wobei man sollte schon etwas auf Browserkompatibilität achten... leider ist das meiner Meinung nach nur selten realisierbar, zumindest wenn man einen realistischen Rahmen für eine Page haben will.

              Das ein "!" nicht hinter jeden Satz gehört auch.

              Steht das in der FAQ!!!! SCNR;)

              Bis denne

              Daniel

              1. hi

                Klar aber am Besten verkauft man doch mit noch einer optischen Unterstützung.

                klar klar...
                aber besser ohne "optische Unterstützung" als bewußt gar nicht, oder?

                Grüße aus Bleckede

                Kai

  7. Er hat vollkommen recht, meine Frage wird nicht mal beantwortet, diese Schweine.!!!!!!!!!!!!