プライマリーキーはchar型かそれとも数値型か

1 ：06/08/23 〜 最終レス ：09/03/20

悩ましい・・実に悩ましい

2 ：

適宜判断する能力もないなら
荷物まとめて田舎に帰れよ無能。
end;
/

3 ：

1です。
>>2の意見に納得しました。
たしかにそれを適宜判断するのが仕事ですね。
あたりまえのことに気付きました。
ありがとうございます。
っていうのはうっそっぴょーんｗｗ
>>2おまえ絶対嫌われ者だろ？ん？正直いってみろクズ
親に虐待されてそだったんじゃない？うふふ

4 ：

Date型

5 ：

それぞれのメリットデメリットを教えてカミタマン

6 ：

クイズ「メリットdeメリット」の時間です。

7 ：

GUID型

8 ：

BLOBで決まり

9 ：

>>3
>1です
ってのは、>>2の意見にかっとなって、
>おまえ絶対嫌われ者だろ？ん？正直いってみろクズ
と書いたところみると、ほんとっぽいな。
他人に煽られてたぐらいで頭にくるくらいなら、クソスレ立てなきゃいいのに。
一番ださいことを>>1=>>3はやってしまった。
しかも、おまけにつまんねぇ。

10 ：

>>9
の意見に怒りのあまりとんでもないことを
しでかした自分に激しく自己嫌悪しています。
ご指摘の通りでございます。
っというのはうっそぴょおおおおおん
>>9　キモオタ低所得はROMってろｗｗ

11 ：

9です。
皆さんを不快にさせて申し訳ありませんでした。
>>2の書込みも自分です。
1さんが>>3の書込みで
　＞親に虐待されてそだったんじゃない？うふふ
とずばり私の育った環境をあててしまったので
どきっとして他人を装ってこんな書込みをしてしまいました。
本当に申しわけありませんでした。
私は幼少の頃から何をするにも親から非難されて育ったので
非常にナイーブで周りの目にびくびくして生きています。
私は生きてる値打ちなんてないゴミ以下の存在です。
皆さんを不快にさせて申し訳ありませんでした。

12 ：

金曜日に投稿して、誰もそれに返事してないのにさらに土曜日に続けに投稿するところみると>>1=>>3=>>10=>>11はよほど
悔しかったのかな。しかも、投稿時刻が朝の４時とか５時で自分からニートであることを
宣言しちゃってるし・・・・・・

13 ：

8です。
ゴミ以下の存在の>>1に罵倒されるのを
楽しみにしていたのにスルーされて悲しいです。

14 ：

ジャッジします。
2が一番クズ

15 ：

LOB型

16 ：

本当の8です
バイナリラージオブジェクトを覚えたてでつい
>>1を茶化そうとこんなつまらない書き込みをしてしまいました
悪いと思ってますん

17 ：

真実の8です。
でも内心では自画自賛しています。
だってさ〜、PRIMARY KEYにBLOBだぜ？
ユーモアのセンス抜群じゃん ﾌﾟﾌﾟﾌﾟ

18 ：

プライマリーキーは数値にすべきです。
速度が段違いです。
それにChar型にするということは、
emailや名前をKeyにすると言うことなのでしょうが
そういうデータは後々重複を要求される可能性が出てきます。
プライマリーキーは数値の連番とかがベストでしょう。
あとの値はユニークにでもしとけ。

19 ：

> プライマリーキーは数値にすべきです。
> 速度が段違いです。
DBMSによります。
> それにChar型にするということは、
CODE39とか知りませんか？

20 ：

>>4
うるう秒とか大変じゃね？

21 ：

そんなマジレスされても。

22 ：

ECの大阪公演の前座に、Charが決定してるらしいよ
詳細は、Charのファンクラブにも電話で問い合わせたらいいと思うよ。

23 ：

ようやく結論が出たな

24 ：

犯人はこの中にいる！

25 ：

ﾊﾝﾆﾝﾊﾔｽ

26 ：

あなたを、犯人です。

27 ：

それはあなたの心です。

28 ：

>>18
>>emailや名前をKeyにすると言うことなのでしょうが
ってまじでいってんの？
Char型で入るのか？
Char型って固定長だぞ？おい解ってるのか？
メールアドレスや名前ならVarchar型にいれんだろ普通

29 ：

>>18
>>プライマリーキーは数値にすべきです。
>>速度が段違いです。
速いよ！大体のDBでは速度向上望めるぞ
でもそれは一人で作業する場合だけな。
3人チームで設計書も書けない馬鹿が数値だけでDB作って、
データの値から全く推測できず、カラム名もなんとなくそれっぽいけど
作った本人以外は解読に少々時間かかる始末。
そんなDBつくってんのは雑魚零細企業のWEBサイトか
サイトくらいなもんだろうなあ。

30 ：

そんなマジレスされても・・・

31 ：

マジレス？
タダの中級者じゃん
結局最後はGUIDに行き着く

32 ：

MACアドレスみたいな文字列をプライマリーキーに使うのか？
どんな膨大なデータに利用するの？
意味解らんそこまでする必要性があるのだろうか
WEBアプリ作るだけでGUID利用しましょうなんてバカ出てくるからだまっとけ

33 ：

でもユニークキーに利用するだけならまあ納得できる。

34 ：

くだらねぇそんなんでいちいち数値にする意味ないよ。

35 ：

山崎剛明は秋葉原でチラシばかり集めるキチガイ野郎

36 ：

不憫だあまりに不憫だ
だあまりにだ

37 ：

>>28
吹いたｗｗｗ

38 ：

プライマリーキーが,,,ない。

39 ：

複数カラムでプライマリキーを構成する場合、charも数値も混在することあるけど。
5個も6個もつなげないとユニークにならないキーも嫌だ。

40 ：

主キーには、Number（可変長）ではなくChar（固定長）だろう

41 ：

チャー

42 ：

キャラって読まないか？

43 ：

リマークでは、チャー、ヴァーチャーと覚えさせられた。

44 ：

レス付けようと思ったら2006年の書き込みだった

45 ：

どう考えても数値がいちばんいい
わかりやすいし処理も速い

46 ：

よくこんなスレがdat落ちしないものだなｗ
この板自体書き込みが少ないからなのか。

47 ：

多くのDBで最高速はINTEGER型だよ
次点がVARCHAR
OracleではCHAR信仰があるけど、殆どのDBではCHARよりVARCHARの方が速い

48 ：

CHAR(4)とINTEGERとプライマリーキーにした場合どう違うんだろうか？

49 ：

データ長は同じだとしても比較の仕方が違うのかな？

50 ：

レコード長の問題じゃない
文字列を比較するのと数字を比較するの、
どっちが高速になるか、プログラマなら解るよな？

51 ：

いや、意外と分からない人がいるんだよ・・・
この前なんか「Accessで比較したら文字列にした方が速かったぞ！」と言い出す人までいたし
(実測値だから本当らしいのだが)｡

52 ：

そういうのに限って突き詰めていくと、
メモリーキャッシュにデーターがロードされていたりする。
早くて当たり前だと。

53 ：

>>50
>>51
分からんな。例えばOracleで、CHAR(8)よりINTEGERの比較の方が速いって
本当に言い切れるか？言い切れるとしたらどういう理由で？
とはいえ、DBのパフォーマンス語る上ではそんなもの誤差でしかないのだがな。

54 ：

>>53
>>47
OracleだけはCHARは特別扱いされてる

55 ：

>>53
そうだとおもう。
100万件のレコードを検索しても、CHAR(8)とINTEGERとの差はコンマ何秒の差だろう。

56 ：

実務経験ない奴かこいつは

57 ：

まあ、文字が長くてしかも文字列中に同じ部分が多いだとか
数字でも浮動小数点の処理が遅いマシンだとか、人生いろいろ
小泉さん見たいなもんだな

58 ：

何秒の差…？
……今日は早く寝よ

59 ：

数字がいちばん

60 ：

INTEGERって言ってるのになんで浮動小数点になるのか解らんが

61 ：

>>47
Cのintなら、そのプラットフォームでもっとも自然で高速に扱える整数型と
されているわけだけど、OracleのINTEGERはNUMBER(38,0)だからなぁ。
しかもBCD。

62 ：

だからORACLEはCHARが最高速ってみんな言ってるのでは。

63 ：

ORACLEは独自規格がおおすぐる

64 ：

ORACLEの独自規格が元になって標準化されてるんだろ？
標準化なんてORACLEの機能にエイリアスをつけてるだけじゃないか

65 ：

信者乙

66 ：09/03/20

オラの糞仕様を囲い込むための標準仕様