- - PR -
主キーの型について(varchar?or char?)
«前のページへ
1|2|3
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-10-04 14:45
失礼なレスかも知れませんが。
CHAR型は固定長なので、長さに満たない値の場合には空白のパディングが行われます。 CHAR型の末尾空白禁止は無理でしょう。 そもそも、値の長さが固定なのか、可変なのかを見極めないで実装する、 かつCHAR型とVARCHAR型の差異を知らないで実装するから問題が発生するのです。 ホストとUnixならWindowsなりの両方の特性をきちんと知らないから故のコメントかと。 | ||||||||
|
投稿日時: 2007-10-05 01:34
charとvarcharの混在で発生するバグ
1.charとvarcharでjoinできない場合がある(末尾の空白が原因で) 2.charでは空白値とnull値があり、null値の代わりに空白値を使用する方がいる varchar派な理由 3.EMPLYEEテーブルとORDERテーブルにEMPNOフィールドがあるとして、 EMPNOフィールドはEMPLYEEテーブルでは主キーだが、ORDERテーブルでは主キーでない。 このとき、EMPNOの型を合わせたい。varcharがいいと思っている。 # 結局、好みの問題では? | ||||||||
|
投稿日時: 2007-10-05 02:31
『主キーだから』という理由で型の設計方針を他の項目と異にする必要ないし、逆にしてはいけない、と思います。
あくまでも、業務要件として可変長の値が入るかどうなのか、またその項目を外部キーなどとして使うようなテーブルがあるならば、そちらでの要件はどうなのか、などを考慮して決定するべき事だと思います。
『混在』というのが何を指しているのかにも拠るのですが、仮に同一の値が格納される項目 ― 例えばあるテーブルでは主キー、あるテーブルでは外部キーに使う、同一の値が格納されるべき項目 ― が、テーブルによってcharだったりvarcharだったりしたら、これはバグになる可能性がありますので、避けるべきと思います。 まったく違う意味の項目でcharとvarcharが混在する、ということであれば、それは問題は無いと思います。(例えば、社員コードを格納する項目はchar、氏名を格納する項目はvarchar、等)
「重大」かどうかについては「そうかもしれない」という風に思いますが、そもそもこれが不具合につながるケースと言うのは、「業務要件として、そもそもがcharである必要が無い」というケースには該当するものが多いのではないでしょうか。 つまり、「右余白が問題になる→入出力等で右余白は必要ない→データの内容そのものとして右余白が不要のものである」ということにならないか、と言う点について検討する必要があるのだと思います。 | ||||||||
|
投稿日時: 2007-10-05 14:32
引用:
-------------------------------------------------------------------------------- 「charとvarcharの混在で発生するバグ 1.charとvarcharでjoinできない場合がある(末尾の空白が原因で) 2.charでは空白値とnull値があり、null値の代わりに空白値を使用する方がいる -------------------------------------------------------------------------------- charとvarcharをjoinすることがおかしいのでは。 joinすると言うことは属性が同じのはずですよね。違う場合には、同じ属性にcastする。 空白値とnullの混同はプロジェクト固有の規約の問題でしょ。 属人的な問題なら、きちんと指摘すればいい話。 | ||||||||
|
投稿日時: 2007-10-06 02:34
実装者は主に向き合うフロントの言語の型としてIntegerとStringとせいぜいDate(time)しか意識しないので、バグが生まれるのでは?と思います。 どちらかというと「時も場所も人も保有技術も国籍も違う人が、 おなじような実装の問題を発生させるのか?」とかそんな観点でのコメントです。 |
«前のページへ
1|2|3