数値をNUMBER型にするかCHAR型にするか。

テーブルのカラムで、2005という文字を格納したい場合、
属性として、NUMBER型、CHAR型の選択ができると思います。

●テーブル名 TABLE1
カラム名 A B
属性 ??? char
データ 2005 XXXX

●テーブル名 TABLE2
カラム名 A C
属性 ??? char
データ 2005 XXXX


このカラムAが、TABLE2のAの2005という値と結合させる
（結合させるためのキーとなっている場合）
ということがある場合、NUMBER型での定義とchar型での定義に
速度的な観点やその他の観点で、なにか差異みたいなものはありますでしょうか？

下記のように、値を指定するところでは、シングルコーテーションが必要か不必要かというのは、あるかと思いますが、
結合自体で、差異はありますでしょうか？



■CHAR型にした場合。
select * form TABLE1,TABLE2
where A='2005'
and TABLE1.A=TABLE2.A

■NUMBER型
select * form TABLE1,TABLE2
where A=2005
and TABLE1.A=TABLE2.A

No.3 ベストアンサー 回答者： noname#87380 回答日時： 2005/10/14 14:54

No.2への回答です。

> 片一方は、CHAR型、もう片方は、VARCHAR2であるというのは、
> 避けたほうが良いということでしょうか？

型違いはできるだけ避けた方が良いかと。

CHARとVARCHAR2は固定長か可変長かの違いがありますので
比較条件に指定した場合、意図しない結果となる場合があります。
例えばCHAR(3)の列とVARCHAR2(3)の列に'A'という文字が
格納されていて、それらを比較しようとした場合ですね。
CHAR型は'A 'という文字列に、VARCHAR2型は'A'という文字列になり
これらを比較した結果、一致ぜず…という事になります。

片方がNUMBER型、もう片方がCHAR型もしくはVARCHAR2型である場合は
比較を行うと一致はしますが、No.2で書いた通り型変換が行われる分だけ
性能面で影響がでてきます。

この回答へのお礼

詳細なご回答本当にありがとうございます。

お礼日時：2005/10/14 20:28

No.4 回答者： mitoneko 回答日時： 2005/10/14 22:48

　型違いのデータを結合・比較・その他の処理をするときには、当然、どちらかの型に他方を「変換」するわけです。

　今回のcharとvarcharの事例ですと、固定長の文字列と可変長の文字列間の変換となります。
　OLACLE上でどちらがどちらに変換され、どのように扱われるかは、No3の方も一部事例をかかれていますように、厳密に定義されています。

　さて、この規約をちゃんと正確に覚えているプログラマーは立派です。少なくとも、私は自信がありません。必要なときには、必ずマニュアルの該当箇所を確認します。(これがましてや、NUMBERとVARCHAR（または、CHAR）となったら、徹底したテストもしたい（苦笑））
　つまり、とっても面倒です。
　世の中、どうしても、その必要があり、必要に迫られて型変換をせざるを得ないことは往々にしてありますが、今から設計するシステムでその必要がないなら、そんなモノはしないのが一番です。プログラムを作成し、修正していく課程で他に考えなくてはいけないことはたくさんあります。なにも、よけいな心配を増やす必然性はさらさらありません。というか、よけいな心配事を一つでも減らしていけるように、データ型というのは設計していくべきでしょう。

　ですから、結論としては、どうしても型違いでなければならない理由が無いのであれば、型は同じにしておくべき。となるでしょうね。

　ちなみに、NUMBERとCHAR(VARCHAR)の選択に関しては、利用用途によっては、まだ他にも考慮点が思いつきます。
　もし、その列でソートするとき、2005と305は、どちらが大きいですか？といった話がプログラム作成に負荷をかける可能性があります。当然、数値としては2005ですが、文字列として考えると、桁あわせをどうするか等いろいろと考える必要があります。本当に、この数字が文字列なら、どちらが大きいかは、「業務の定義による」というのが正解ですし…。

　基本的には、その項目で計算をするかどうかと言うよりは、業務としての定義上、その項目が数・数値なのか、それとも、０～９までの文字を使用した文字列（符号）なのか、そのどちらかによって決定するのが、経験上、プログラムもシンプルになるように思います。
　蛇足ですが、業務上の定義によっては、それは、DATE型ではありませんか？というのも一つの選択肢としてあり得るかと。

この回答へのお礼

ご回答本当にありがとうございます。

お礼日時：2005/10/18 21:14

No.2 回答者： noname#87380 回答日時： 2005/10/14 10:57

こんにちは。

私も No.1 PCFREAK様と同意見です。
(なのでポイント辞退。
同じ意見の人が同じ事を書いてるな…くらいに考えてくださいな^^;)

結合時、TABLE1のカラムAとTABLE2のカラムAの型が
それぞれ違った場合は、暗黙の型変換が生じますので影響があります。
しかし今回の場合は同じ型という事で差異がありません。

型の違いによる差異ですが
　固定長より可変長の方がサイズが小さい
　　　↓
　全体的にレコードを格納するブロック数が少なくなる
　　　↓
　読み取り時のブロック数が少なくなり、読み取り性能に差が出る
という考えです。
今回はデータサイズにほどんど差がないため影響がない程度と思います。

あと…
キー項目には、連番以外の目的でNUMBER型を使うとアプリ開発者側に
色々と誤解を生じさせてしまう事があるので、私も使わないようにしてます。

この回答へのお礼

回答ありがとうございます。

型の違いによる差異について、もう少しお教え願えますでしょうか？

片一方は、CHAR型、もう片方は、VARCHAR2であるというのは、
避けたほうが良いということでしょうか？

お礼日時：2005/10/14 12:56

No.1 回答者： PCFREAK 回答日時： 2005/10/13 23:45

結合自体には差がありません。

速度的には、若干NUMBERの方が速いのではと予想出来ますが、ほぼ無視できる差だと思われます。

どちらを採用するかは設計思想に依存しますね。
数値として取り扱うのであればNUMBER型ですが、文字として扱うのであればCHAR型を使うのが正でしょう。

私個人的にはキーにNUMBER型を使うのは極力好ましくない（特別な理由があるのであれば別ですが。）と考えている為、CHAR型（厳密にはVARCHAR2型）を採用する事が多いです。

この回答へのお礼

回答ありがとうございます。

その値を使って計算させるわけではないので、CHAR型にしようと思います。

PCFREAK様は、キーにNUMBER型を使うのは極力好ましくないとありますが、
それは、なんでなのでしょうか？

また、「厳密にはVARCHAR2」とおっしゃってますが、
それは、なにか意図があるのでしょうか？

知識不足で申し訳ありませんが、よろしくお願いいたします。

お礼日時：2005/10/14 12:51