前任者が作ったデータベースに日付を格納する date つーフィールドがあって、なぜかそこに10バイトものサイズを割り当てているのが謎だった。
今まで作られているデータベースが全部そういう感じなので、何か深遠な理由があってそうなっているのかなと、わしも深く考えず前例に習っていた。
今日、テーブルを眺めてて、tel1 tel2 tel3 などと電話番号を3分割してあって、、それに tinyint(5) とかそれぞれ割り当てられているのだが、 127 127 とか、明らかにやっちゃった感のある16進数的に非常にありがちな数値が入っている。
また、郵便番号も zip1 zip2 と分割されていて、tinyint(3) tinyint(4)なんて割り当てられている。
tinyint は多分1バイトで signedで-128～127 の値を取るので 127よりも大きな「数値」をぶち込んで、127にされてんだろーなあと想像がつく。
で、tinyint で確保しているバイト数には何の意味があるのかと思えば、ああ、なるほどね。mySQLでフィールドを作る時に割り当てる数字を実際に使用する桁数だと勘違いしてんだな。
だから、php の time() の数字をぶっこむ date ってフィールドに32bit処理系ならunsigned の4バイトで十分なところ、10桁のつもりで、10バイトもの広大な領域を割り当ててんだな。
なぜmySQLで 1バイトしか使わないのにそれ以上のサイズ割り当てが できるようになっているのかというのは、処理系によっては奇数メモリアドレスアクセスでクロック数を食ってしまうペナルティがあるので、恐らく、それを回避する為にバイト境界が変えられるようにしてある気がする。
バイト境界とかその辺の概念が無い場合、VARCHARみたいに文字数を設定するって勘違いしても不思議では無いが、「過去のソフトウエア資産」がこういう感じで、ライブラリに実績があり、正しいという前提条件でプログラムを組むと、酷い目に遭う訳だな。