ここ数年携わったプロジェクトの幾つかのRDBのテーブル定義は、文字列属性がすべてvarchar2(n)でした。長さ1byteの項目でも、キー項目でも、複数項目からなる項目でも一律にvarchar2(n)です。
可変長の扱いはOverHeadが高い、Update処理の時、有効な項目データ長が確保されている行領域を超えるときは、行が取り直されるので置換コストが高くつく。というコスト意識がまず浮かんでスナオに賛成できません。
別の面では、項目長の意味合いが崩れる。とも思うのです。8byteの顧客コードのシステムの場合、「８桁の顧客コード」という桁数に意味があるケースもあります。"1234 "が "1234" になるのでは
意味が変わってくることもあります。
また、顧客コードを varchar2(8) にしているシステムと、char(8)としていいるシステムと連動したとき, '1234' = '1234 ' が成立しないので、要らぬ手間が生じたり、不毛なバグ騒ぎになったりします。
桁が固定している項目は固定長にしましょうと主張すると返ってくる反論は 「RDBもCPUも進歩して早くなっているのだから、varchar2()によるコストアップは知れている。それよりも、varchar2()で統一するメリットのほうが大である。他のシステムもvarchar2()に置換すべきだ。」
うーん。いいのかなぁ。引っかかるなぁ。古い感覚から脱皮できないのかなぁ。
varchar2() と char() の 動作振る舞いの差を認識したうえで、varchar2()に統一しているのなら一理あるようにも思います。しかし、それがインフラになっていると、初心者にとってはそれが当たり前になってしまい、違いを知ろうとしない開発者になったりします。
安易に作れるようになると、浅い開発者が増えるのは痛し痒しですね。
それとはまったく別次元の話ですが , Varchar2()の'2'に違和感を感じてます。 マジックナンバー感がするのです。
以前のORACLEはvarchar()があり拡張型として varchar2()が登場した背景があります。しかし、"2"にするのは軽いと思うのです。拡張やexpansionにナンバーを付けるセンスが如何とも。
PowerShellの拡張子が、PS1 というのもあり、末尾に数字を付ける文化って不滅なのかなぁ。
名は体を表わすべきだし、マジックナンバーは止めましょうと推進しているインフラ的な製品に"2" が付くのは落ち着かないです。