- PR -

CHARに対するVARCHARの欠点

«前のページへ 1|2
投稿者投稿内容
maru
ぬし
会議室デビュー日: 2003/01/27
投稿数: 412
投稿日時: 2003-07-12 16:15
こんにちは。

付け加えますが、行連鎖でパフォーマンスに多少影響があるというのは、あくまで理論的
なはなしで実際には、ディスクI/Oやメモリチューニング、SQLの書き方やネットワークI/O
などそれ以外の要因も総合してパフォーマンスに出ます。
パフォーマンスに関しては広い視野でバランスよく考える必要があります。
しかし、私は行連鎖でのパフォーマンスに関してそんなにシビアに考えたことがなく、
いつも感覚的ですが。

今回の部門コードや製品コードはそのような理由であれば、単純に列の性質として可変長
データと考えてVARCHAR2にしたらいいのでは？
コードなので更新のたびに桁数がころころ変わるわけでもないし、固定長で無駄なデータ
数を確保する必要もないので。

>プログラマがミスしにくいようには設計した方がよいですよね。
それは確かにそうです。

ただ、「列が（将来性も考え）可変長のものはVARCHAR2にする」と列の性質を考慮して
ならデータベース設計として理解できますが、「空白操作が大変だからVARCHAR2にする」
という視点ではどうかと思ったのでした。
みやも
ベテラン
会議室デビュー日: 2002/04/22
投稿数: 74
投稿日時: 2003-07-14 21:25
アドバイスありがとうございます。

例のようなケースの場合、以下の理由でVARCHAR2にするということで、自分が納得＆他の人を納得させれそうです。

・列が可変長
・変更が少ない
・パフォーマンスへは大きく影響しない


>これがDB変更したい理由であればラッパークラスを作るほうが早いんじゃ
って思います。やることははっきりしてますよね。

そうですね。共通化できるところは、先行で作成してみます。
今回の場合、アプリ側で空白パディングするために、DBカラムの桁数をアプリ側で知っておく必要があるのがちょっと難点でした。MetaDataを使うなど、方法はありそうですが、若干難しそう。でも、同じ問題にまた出くわしそうだし、作っとくと便利かなぁ。

«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）