Performance und Datentypen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Performance und Datentypen

    Wie wirken sich unpassende bzw. ungünstige Datentypen auf die Performance bezüglich des Zugriffs aus?
    Dieses Schreiben wurde automatisch erstellt und ist ohne Unterschrift gültig.

  • #2
    Ungenaue Datentypen verschwenden zumindest Speicherplatz. Ob MySQL dadurch so sehr an Performance einbusst, kann ich nicht sagen, vorteilhaft ist es für die Performance aber sicher nicht.
    [color="#334D7B"]"Los, lass uns loslegen! Hm ? Quatschen können wir hinterher immer noch!"[/color]
    [color="#9C5245"]"Aber Bommel, wir können jetzt nicht bumsen. Wir müssen doch erst den Kindern - ... "[/color]
    [color="#334D7B"]"Ja ja ja. Du willst immer nur das Eine. Buchstabenzeigen, Buchstabenzeigen - meine Gefühle sind dir wohl scheißegal."[/color]

    © Harald Schmidt

    Kommentar


    • #3
      Schließe mich an. Ungenaue Datentypen wirken sich ungünstig auf die Performance aus.
      Extremfall: Stell Dir vor Du hast Integerwerte und definierst für diese ein BOLB

      Kommentar


      • #4
        Original geschrieben von hand

        Extremfall: Stell Dir vor Du hast Integerwerte und definierst für diese ein BOLB
        sehr extrem

        ich dachte eher an fälle, wo z.B. MEDIUMTEXT verwendet wird, obwohl TINYTEXT reichen würde.

        gibt es eine möglichkeit, diese unterschiede und die daraus resultierende performance festzuhalten, auzuwerten (eventuell grafisch darstellen) etc.

        also eine art benchmark für DBs, sowas gibt es doch bestimmt....
        Dieses Schreiben wurde automatisch erstellt und ist ohne Unterschrift gültig.

        Kommentar


        • #5
          Ich denke ob MEDIUMTEXT oder TINYTEXT verwendet wird, spielt betreffend Performance eine vernachlässigbare Rolle, wenn überhaupt.

          Man könnte so einen Benchmark selbst irgendwie hinzaubern. Aber ich glaube nicht, daß diese Dinge so einfach meßbar sind. Plattenzugriffe, Cachemechanismen, Hauptspeicher, Parallelprozesse, ...., all das beeinflusst das Antwortverhalten.

          Viel einfacher sind Queries zu optimieren, denn da bieten sich viele Faktoren an, die das Antwortzeitverhalten negativ beeinflussen könnten. Wenn diese optimiert sind, erst dann kann man daran gehen weiter zu forschen. Da ist es aber sicher schon einfacher Memory oder performantere Platten zu kaufen. Über Parameter läßt sich MySQL selbst tunen, denn es ist schon ein Unterschied ob vornehmlich die Daten lediglich abgefragt werden, die Daten hauptsächlich verändert, oder hauptsächlich Records eingefügt werden.

          Wenn man sich über die wesentlichen Dinge wie Integer nach Integer im Klaren ist und dann noch in einem vernünftigen Maß die Indizes legt, dann glaube ich hat ein Programmierer schon immens viel zur resourcenschonenden Nutzung einer DB beigetragen.

          Datentypen lassen sich über Export/Import relativ einfach nachjustieren. Weniger easy ist das mit dem Datenmodell, wenn bereits Programme auf selbigem aufbauen.

          Es gibt kein Standard-Rezept zur Erstellung "performanter DB-Applikation". Es ist eine Mischung zu vieler Faktoren. Mitunter kann man ein hyperperformantes Datenmodell kreieren mit dem Resultat, daß es kaum möglich ist einfache Queries abzusetzen und das widerspricht voll und ganz der Usability.

          Kommentar


          • #6
            Vielleicht ist das hier hilfreich: The Open Source Database Benchmark
            mein Sport: mein Frühstück: meine Arbeit:

            Sämtliche Code-Schnipsel sind im Allgemeinen nicht getestet und werden ohne Gewähr auf Fehlerfreiheit und Korrektheit gepostet.

            Kommentar

            Lädt...
            X