Peter Müller: Bewerbungsbogen

Hallo,

bin gerade dabei einen Bewerbungsbogen für einen Job im Ausland auszufüllen. Dabei komme ich mit der folgenden Frage nicht klar.

Your thoughts about MySQL:
 - (My)SQL  I rather use text files.
 - JOINs are expensive, but who cares?
 - Primary keys are unnecessary fuss.
 - Indices result faster data INSERTs

Ich soll mich dabei für eine Antwort entscheiden. Meiner Meinung nach kann man den 3. und 4. Anstrich ausschließen, weil Primary keys sind sehr wohl notwendig bei Datenbanken und Indexe helfen nur bei SELECTs und nicht bei INSERTs.

Was denkt Ihr?

  1. Moin!

    bin gerade dabei einen Bewerbungsbogen für einen Job im Ausland auszufüllen. Dabei komme ich mit der folgenden Frage nicht klar.

    Das ist ja keine Frage im Sinne von "richtig oder falsch", sondern es geht um deine Ansichten.

    Your thoughts about MySQL:

    • (My)SQL  I rather use text files.

    "Von Datenbanken halte ich lieber Abstand."

    • JOINs are expensive, but who cares?

    "MySQL - ja bitte, für alles, was geht."

    • Primary keys are unnecessary fuss.

    "MySQL - ich benutze es, weiß aber nicht, wie man es richtig macht."

    • Indices result faster data INSERTs

    "MySQL - ich hab komplett keine Ahnung davon, und mach mich gerade voll zum Pansen, aber ich will um jeden Preis mitreden."

    Was denkt Ihr?

    Your thoughts about MySQL?

    - Sven Rautenberg

    --
    My sssignature, my preciousssss!
    1. Hallo,

      • Indices result faster data INSERTs

      "MySQL - ich hab komplett keine Ahnung davon, und mach mich gerade voll zum Pansen, aber ich will um jeden Preis mitreden."

      ICH = Pansen! :)

      Wie ist denn das bei Unique-Attributen? MYSQL müsste ja dann beim Insert alle bestehen Attribute prüfen, um zu gewährleisten, dass beim Insert kein doppeltes Attribut eingefügt wird.

      Wenn MYSQL für das Abrufen bestehender Attribute einen Index benutzt, müsste das doch schneller gehen, oder nicht? Folglich wäre ein "INSERT" unter dieser Bedingung einen Tick schneller.

      Oder hab ich da jetzt komplett einen Knick in den Hirnwindungen?

      1. hi,

        Wie ist denn das bei Unique-Attributen? MYSQL müsste ja dann beim Insert alle bestehen Attribute prüfen, um zu gewährleisten, dass beim Insert kein doppeltes Attribut eingefügt wird.

        Ja, natürlich.
        Das geht aber recht fix, weil UNIQUE ja schon ein Index _ist_. Auf diesem kann schnell die Suche durchgeführt werden, im Grunde genau das gleiche wie bei einem SELECT mit eindeutiger und singulärer WHERE-Bedingung.

        Wenn MYSQL für das Abrufen bestehender Attribute einen Index benutzt, müsste das doch schneller gehen, oder nicht?

        Deshalb macht's das ja auch :-)

        Folglich wäre ein "INSERT" unter dieser Bedingung einen Tick schneller.

        Jein.
        Die Meldung, dass der Insert nicht ausgeführt werden konnte, weil er einen UNIQUE INDEX verletzen würde, die bekommst du natürlich recht fix, siehe oben.
        Was länger dauert, ist ein erfolgreicher INSERT - weil "nach" diesem ja der Index aktualisiert werden muss. _Das_ kostet Zeit, weil das ja nicht mit dem simplen anfügen des neuen Index-Wertes getan ist, sondern auch eine Sortierung wieder hergestellt werden muss (z.B. binärer Suchbaum o.ä.).

        gruß,
        wahsaga

        --
        /voodoo.css:
        #GeorgeWBush { position:absolute; bottom:-6ft; }
        1. Hallo wahsaga,

          Folglich wäre ein "INSERT" unter dieser Bedingung einen Tick schneller.
          Jein.

          mit Deinem "J" bin ich nicht einverstanden.

          Die Meldung, dass der Insert nicht ausgeführt werden konnte, weil er einen UNIQUE INDEX verletzen würde, die bekommst du natürlich recht fix, siehe oben.

          Wann ist eine Prüfung auf Verletzung eines eindeutigen Indexes erforderlich?
          Klar, nur wenn ein Index überhaupt vorhanden ist. Somit kostet der eindeutige Index zweimal Zeit beim Einfügen:

          1. Zeitfaktor: Prüfung
             Daraus kann ich kein J sondern nur ein *N* ableiten :-)
          2. Zeitfaktor: Aktualisierung des Indexes.

          Ein Index ohne Eindeutigkeit kostet (wie Du geschrieben hast) nur einmal Zeit:

          1. Zeitfaktor: Aktualisierung

          Der zusätzliche Zeitaufwand ist bei einem eindeutigen Index sogar noch höher als bei einem nicht eindeutigen Index.

          Freundliche Grüße

          Vinzenz

          1. hi,

            mit Deinem "J" bin ich nicht einverstanden.

            Jeinverstanden.

            Somit kostet der eindeutige Index zweimal Zeit beim Einfügen: [...]

            Ja, natürlich.

            Der zusätzliche Zeitaufwand ist bei einem eindeutigen Index sogar noch höher als bei einem nicht eindeutigen Index.

            Nichts anderes hätte ich je behaupten wollen.
            Sollte ich es doch getan haben :-), dann habe ich wohl Jörgs Frage fehlinterpretiert, bzw. missverstanden von welcher "Bedingung" beim Insert da überhaupt die Rede war.

            gruß,
            wahsaga

            --
            /voodoo.css:
            #GeorgeWBush { position:absolute; bottom:-6ft; }
            1. *patsch* Ok, verstanden. Mein Denkfehler war, dass ich vergaß, dass UNIQUE-Attribute ja automatisch in einem Index organisiert werden. (siehe wahsagas Antwort).

              Wenn das Attribut dann noch ZUSÄTZLICH wo eingehängt werden muss, ists natürlich was anderes.

              Muss mal den ganzen Datenbank-Architekturkram wieder auffrischen *vornehm*