Datentypen: So klein wie möglich, so groß wie nötig

Jede Spalte in einer Tabelle hat einen Datentyp. Einige sind untereinander kompatibel, andere weniger. Um sämtliche Prozesse der Datenbank zu beschleunigen, ist es ratsam die Datentypen clever zu wählen und nicht „frei Schnauze“ einfach bei allen Ganzzahlen BIGINT zu nehmen, denn „das wird schon funktionieren“. Sicherlich funktionierts – nur zu welchem Preis?

Für eine optimale Wahl der Datentypen sollte man die Wertebereiche, die sie jeweils abdecken, entweder im Kopf haben oder wissen, wo sie stehen. Eine allgemeine Empfehlung, wleche Datentypen gut und welche b öse sind, kann es natürlich nicht geben, denn alle haben für bestimmte Anwendungsbereiche ihre Berechtigung.
Wenn allerdings jemand die ID in einer Kategorientabelle als BIGINT definiert, ist das nicht dem Anwendungsbereich entsprechend (es sei denn, man erwartet 2^63 Kategorien, was recht unwahrscheinlich ist). Deshalb immer die Überschrift dieses Artikels im Auge behalten: Der Datentyp sollte so klein wie möglich gewählt werden (möglichst kleiner Wertebreich), aber natürlich so groß wie nötig (niemandem ist geholfen, wenn in einem Online-Shop der Artikelname nur 10 Zeichen haben darf).

Folgende Regeln gelten aber immer und helfen bei der Wahl des „richtigen“ Datentyps:

  • INTEGER statt DECIMAL (bzw. FLOAT / DOUBLE), wenn nur Ganzzahlen benötigt werden
  • INT statt BIGINT (sie wissen, wie es gemeint ist – genauso SMALLINT statt INT – je nachdem, wie groß der zu erwartende Wertebereich der Daten ist)
  • VARCHAR statt CHAR (für CHAR wird immer so viel Speicherplatz benötigt, wie die Länge beträgt, bei VARCHAR nur so viel, wie die eigentlichen Daten belegen)
  • VARCHAR(60) statt VARCHAR(255) (auch hier muss Obacht gegeben werden, mir passiert: Telefonnummer als VARCHAR(20) gespeichert. Und dann kam jemand aus Österreich, der Landesvorwahl mit + und Klammern eingeben hat und dann wurde die Nummer eben abgeschnitten – es ist also Vorsicht geboten wie bei den anderen Datentypen auch)

Nun sind die Datentypen also optimiert. des Weiteren sollte man darauf achten, möglichst viele Spalten als NOT NULL zu definieren, denn NULL-Werte sind besonders bei COUNT(*) und Joins immer eine Bremse. Prüfen sie aber vorher Ihre Anwendung, was passiert, wenn beispielsweise bei INT-Feldern plötzlich statt dem NULL eine 0 drinsteht.

Und ganz wichtig: Wenn Tabellen normalisiert werden, wird in der einen ein Primärschlüssel festgelegt und in der „Partnertabelle“ ein Fremdschlüssel, der auf den Primärschlüssel veweist. Diese sollten unbedingt den gleichen Datentyp haben, da sonst der Index nicht angewendet werden kann zum Joinen.

Jan hat 152 Beiträge geschrieben

7 Kommentare zu “Datentypen: So klein wie möglich, so groß wie nötig

  1. Bei meiner DB habe ich auch sehr lange überlegt und einen Fachmann zu Rate gezogen, wie und wo welcher Spaltentyp geeignet ist. Kommentare-Namen werden bei mir beispielsweise auf 140 Zeichen gekürzt, warum also im Varchar-Feld 255 Zeichen dafür reservieren?

    Ich denke das ist ein sehr guter Ansatz für die Beschleuigung der eigenen PHP-Anwendung in Verbindung mit einer Datenbank.

    PS. Wie wäre es, wenn du die Linkarena als Bookmark Service hinzufügen würdest? Wäre nice!

  2. Jo sagt:

    Hallo!
    Verfolge ebenfalls deinen Blog, sehr spannend und etwas was ich mir schon lange gewünscht habe.

    Wie würdest du einen String von max. 15 Zeichen speichern, als CHAR(15) oder VARCHAR(15)? Klar braucht VARCHAR mehr Speicher, aber defür geht dann das fixe Tabellenformat drauf..
    So aus dem Bauch raus – ist ein fixes Tabellenformat oder eine geringere Tabellengrösse performanter? Hast du da Erfahrungen?

  3. admin sagt:

    Hast dich glaube verschrieben: VARCHAR braucht weniger Speicher als CHAR, denn es füllt ja den restlichen Platz nicht auf.
    Für Dich könnte der Beitrag der SQL Junkies interessant sein. Shcnell gesagt: Bei Selects kein Untershcied, bei Inserts ist die Varchar-Version schneller, bei Updates ist Char schneller.
    Bitte benutze für solche Fragen in Zukunft aber das Forum, das ich extra dafür eingerichtet habe.

    PS: Und da ist sie: die Linkarena 😉

  4. IcyT sagt:

    „Jo“ hat schon Recht: Wenn beide Zeichenketten gleich lang sind, dann benötigt VARCHAR genau 1 Byte mehr, denn darin wird die Längeninformation gespeichert. Also wenn man beispielsweise einen MD5-Hash speichert, dann ist ein CHAR(32) besser, als ein VARCHAR(32), denn ein MD5-Hash ist IMMER 32 Zeichen groß. Somit würde er bei CHAR(32) genau 32 Bytes benötigen und bei einem VARCHAR(32) genau 33 Bytes. Ich verweise auf die MySQL-Dokumentation.

Eine Antwort schreiben

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert mit *

You may use these HTML tags and attributes: <a href=""> <blockquote cite=""> <pre lang=""> <b> <strong> <i> <em>