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


PouchDB – CouchDB mit Javascript
Ich habe ja schon desöfteren verkündet, das man nicht alles mit MySQL todschlagen muss. Zum einen gibt es sinnvolle Key-Value-Stores, zum anderen Date...


Events in MySQL – das ungeliebte Kind
Events in MySQL ist eine Technik, die ähnliche wie Triggers und Stored Procedures kaum Verwendung finden. Das wiederum liegt an der Tatsache (und man ...


SQLite mit Lita administrieren
Zugegebenermaßen ist SQLite nicht weit verbreitet – denkt man zumindest ;) 98% der Webworker nutzen MySQL und rücken von diesem Standard keinen Zentim...


MemSQL – der angeblich schnellste SQL-Server
MemSQL hyped sich ja jetzt seit Wochen durch die Medien, und das nicht ohne Halbwahrheiten zu begünstigen, oder ominöse Fehler - die durchaus vorhande...

Kommentare

  1. Arnd

    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.