Früher war es sehr oft üblich, varchar(255) an jede Hauswand zu sprühen, wo Text in MySQL zu speichern war. In letzter Zeit sehe ich häufig varchar(32), varchar(64) und so weiter in verschiedenen Datenbank-Layouts. Ist das besser? Welche Länge ist eigentlich gut? In diversen Foren wird über varchar diskutiert, denn es ist oft ein entscheidendes Performance-Kriterium.
Wollten die PHP-Entwickler nicht PHP 6 unbedingt vor Perl 6 fertigstellen? Naja, mit PHP-Version 5.3 haben wir immerhin ein halbes PHP 6 bekommen. Was jetzt noch fehlt, ist das geplante Unicode-Ding. Was allerdings nicht so schmerzt…finde ich.
Gratulation an dieser Stelle an die Perl-Gurus, die sich unter anderem mit neuen OOP-Features auf unbekannte Wiesen und Felder begeben können…ich wünsche auf jeden viel Spaß beim Coden.
PS: Ich bin mir ganz sicher: Eines Tages werden außerirdische Archäologen Perl-Code finden und ihn für prähistorische Hieroglyphen halten!
Letzte Woche bin ich mit MySQL fast verzweifelt. Irgendwie haute die ganze Kodierung nicht mehr hin. Das Backup hatte auf einmal zerrissene Umlaute, und nichts konnte es bewegen, es wieder richtig zu stellen. Nach verzweifelter Suche fiel mir der Fehler auf: Terminal, Verbindung, MySQL – all das muss passen. Und da hatte sich der kleine Fehlerteufel eingeschlichen: WordPress hielt es nicht für nötig, die Tabellen auf die benutzte Kodierung umzustellen. Hier gleich die Entwarnung: Die aktuelle WordPress-Version 2.7.1 tut das auf jeden Fall ordentlich.
Auf jeden Fall hat es mich angespornt, zu diesem Thema einen kleinen Beitrag zu verfassen. Und so fange ich mit einem kurzen Abschweifer eines geschichtlichen Abrisses an, um dann später auf die Einstellung des Linux-Basissystems zu sprechen zu kommen. Weil damit schon so viel Text durch den Äther fliegt, kommt MySQL etwas später dran.
