固定長→可変長
先日Web2.0なんてハイカラなことを書いたばかりだけど、急に固定長マインドと可変長マインドの間のギャップ、なんて古い話が気になっている。
固定長、を日常意識することは少ないんだけど、例えば何かの申込書での氏名入力欄や電話番号入力欄(ていうか電話番号)は、字数制限のあるデータの代表例だ。こういうのは保存されるときに「たかだか固定的な長さ以内」と制限されるため、容量や処理性能の把握が楽だ、というコンピュータ視点でのラクさがある。
そして多くのシステム屋は固定長でデータができることをよしとする。
が、これはコンピュータの処理能力が低かった頃の名残と、COBOL時代の癖でしかないと僕は考えている。
(現在でも、コンピュータにとっては、stream のポインタを固定長だけ移動させるのと、終了条件に辿り着くまで文字コードを見ながらポインタを移動させるのでは、前者が圧倒的に速いのは事実だ。だから多くのDBはデータの項目ごとに最大長を指定する)
このため、氏名は固定長でいいの? とか、電話番号は固定的なのが望ましいの? という議論がなされることは少なく、本来は可変長なほうが自然なのに、固定長を押し付けられる場合が多いことに、ギャップを感じるのだ。
例えばドメイン名やURLはどうだろう。厳密には最大文字数はあるけど、これが固定幅だと意識することは少ない。だからこそ、こんだけバリエーションのあるドメインやコンテンツが存在し、日々増殖しているのだ。そしてパスワードは通常可変長だ。(たまに固定長を要求するアホなのもあるけど)blogのエントリも可変長だ。人間が表現できる事象は可変長のほうが多いのだ。
が、固定長マインドというのは根強く、たとえばおおよそ全てのコンパイラにとって、変数名や関数名は可変長なのに、未だに関数名や変数名を固定幅で設計する人は実際いる。
ということで、DB屋は「本当に固定長が望ましいのか」という視点でデータを設計して欲しいし、可変長が許されている環境なのに、固定長にしようとしていないか、という振り返りをして欲しいなーと思うのだ。
固定長、を日常意識することは少ないんだけど、例えば何かの申込書での氏名入力欄や電話番号入力欄(ていうか電話番号)は、字数制限のあるデータの代表例だ。こういうのは保存されるときに「たかだか固定的な長さ以内」と制限されるため、容量や処理性能の把握が楽だ、というコンピュータ視点でのラクさがある。
そして多くのシステム屋は固定長でデータができることをよしとする。
が、これはコンピュータの処理能力が低かった頃の名残と、COBOL時代の癖でしかないと僕は考えている。
(現在でも、コンピュータにとっては、stream のポインタを固定長だけ移動させるのと、終了条件に辿り着くまで文字コードを見ながらポインタを移動させるのでは、前者が圧倒的に速いのは事実だ。だから多くのDBはデータの項目ごとに最大長を指定する)
このため、氏名は固定長でいいの? とか、電話番号は固定的なのが望ましいの? という議論がなされることは少なく、本来は可変長なほうが自然なのに、固定長を押し付けられる場合が多いことに、ギャップを感じるのだ。
例えばドメイン名やURLはどうだろう。厳密には最大文字数はあるけど、これが固定幅だと意識することは少ない。だからこそ、こんだけバリエーションのあるドメインやコンテンツが存在し、日々増殖しているのだ。そしてパスワードは通常可変長だ。(たまに固定長を要求するアホなのもあるけど)blogのエントリも可変長だ。人間が表現できる事象は可変長のほうが多いのだ。
が、固定長マインドというのは根強く、たとえばおおよそ全てのコンパイラにとって、変数名や関数名は可変長なのに、未だに関数名や変数名を固定幅で設計する人は実際いる。
ということで、DB屋は「本当に固定長が望ましいのか」という視点でデータを設計して欲しいし、可変長が許されている環境なのに、固定長にしようとしていないか、という振り返りをして欲しいなーと思うのだ。
inet | - | -