nicht angemeldet
yo,
es geht aber um mysql und da sollte man auch das nutzen was zur verfügung steht.
das sehe ich anders, es geht weniger primär um mysql, sondern um die datenhaltung. und oftmals durchlaufen die daten mehrere verschiedene systeme zur haltung und pflege der daten. wenn ich dann die option habe, es "allgemeingültiger" zu lösen, ist das durchaus ein sinnvolles argument. oracle kennt zum beispiel zwei verschiedene notationen einen outer join zu bilden, einen nach ansi (ab 9i) und einen oracle eigenen weg. es gibt eigentlich somit keinen grund mehr, nicht den ansi weg zu nehmen.
und vorallem nur eine einstellung (und zwar innerhalb des DBMS) verlangt halte ich ZEROFILL eindeutig für die bessere variante, ansonsten müssten ja alle abfragen angepasst werden, was die sache nur unnötig kompilierter machen würde..
kontrollierbarkeit ist ein weiterer wichtiger aspekt. allerdings ist dies nicht nur mit zerofill zu erreichen. trigger lösen das problem ebenfalls und diese kennen auch alle dbms mit einem professionellen anspruch. dazu kenne ich firmen, welche die fachlichkeit nicht in das dbms abgeben, sondern es in einer klasse hinterlegen.
dazu kommt noch, dass zerofill nur funktioniert, wenn ich den datentyp so wähle, dass er die richtige länge hat. damit schaffe ich eine abhängigkeit, die ich gar nicht will, zum beiuspiel weil ich den datentype größer wählen will.
aber das ko kriterium für mich ist immer noch, dass ich dann die kundennummer nicht als string verwenden könnte. unter dem strich würde ich weiterhin lpad verwenden, wenn ich es auf datenbank-ebene lösen sollte.
Ilja