MySQL – Optimale Größe für Feldtypen

Was ich wirklich und mit aller Leidenschaft hasse, sind Programmierer die im Fire&Forget-Stil Größen von Feldtypen in MySQL setzen – und dann auch noch Größen, die nicht durch zwei teilbar sind! Ich kriege wirklich JEDES MAL einen Anfall, wenn mir HeidiSQL für einen varchar eine Größe von 50 Zeichen vorgibt. Genauso wie die Tatsache, alles aufs Maximum zu setzen. Wenn man ein 8 Zeichen langes Passwort in ein varchar(255) steckt, passt da wohl was nicht. Vor allem der unnötige inflationäre Einsatz von Blobs und Text gibt mir zu denken. Ich weiss das heute alles besser ist, aber „früher“ wurde sogar empfohlen, Blobs stets in eigene Tables zu packen.

Screenshot der MySQL Procedure Analyse Homepage

Spätestens jetzt springen wohl die ersten aus der Kiste und meinen, das würde heute nichts mehr machen, Festplatten wären weit und läufig, und CPUs schnell. Und überhaupt: große Feldtypen sind zukunftssicher! Wenn man da seine 10 Hörbücher drin verwaltet und die man einmal pro Woche durchsucht, mag das wohl stimmen. Arbeitet man mit großen Datenmengen in Kombination mit Volltextsuche oder der Abartigkeit, dass PHP evtl. bei großen Selects alles im Speicher hält, plus einer netten Auslastung, wird man wohl spätestens merken, das man sich vielleicht etwas mehr Mühe hätte geben können. Das nicht mehr vorhandene Wissen um die Normalisierung von Daten lasse ich grad mal aussen vor! ;)

Als nächstes wird jetzt wohl das Argument kommen, dass man gar nicht weiss, wie groß die Daten sind die abgespeichert werden sollen. Und spätestens jetzt hat man sich wohl endgültig disqualifiziert. Zum einen werden (wenn es dann ein Web-Anwendung ist) die Größen von den Eingabefeldern vorgegeben, zum anderen materialisieren sich Daten nicht einfach in der Datenbank, sondern man könnte die auch vorher mal analysieren.

Ein kleiner Tipp an der Stelle ist, dass man sich mal den MySQL-Befehl PROCEDURE ANALYSE anschaut, der sagt einem nämlich was Sache ist! Und wenn ihr einen Table nachträglich einkürzt denkt dran, ihn zu optimieren!

Ähnliche Beiträge

MyWebSQL – als Alternative zu phpMyAdmin (re... Meine Meinung zu phpMyAdmin habe ich ja schon ausreichend verkündet: es hat seine Zeit gehabt, nun ist aber auch gut. Leider setzen noch alle großen P...
Optimierung von Webseiten mit dem Jet Profiler Ich habe ja bereits vor einiger Zeit über den Jet Profiler berichtet, bei dem es sich um einen Profiler für MySQL handelt, der unter anderem Slow Quer...
Brave new World: Was ist eigentlich NoSQL !? Derzeit entsteht ein regelrechter Hype um die sogenannten NoSQL-Datenbanken wie zum Beispiel CouchDB oder MongoDB, aber was ist das eigentlich? Wie de...
Chive – eine phpMyAdmin-Alternative !? Meine Meinung über phpMyAdmin dürfte inzwischen hinlänglich bekannt sein, um so interessierter bin ich an Alternativen wie zum Beispiel den Adminer. M...

Eine Antwort auf „MySQL – Optimale Größe für Feldtypen“

  1. Warum sollte ein VARCHAR immer eine durch zwei teilbare Länge haben?

    Ist es nicht sinnvoll, wenn möglich, feste Feld-Längen zu wählen, weil dann MySQL nicht gucken muss, wo das nächste Feld beginnt? Also CHAR statt VARCHAR. Bzw. TINYTEXT statt VARCHAR(255).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.