【恐怖】主キーがないテーブルみたことありますか？

1 ：03/11/20 〜 最終レス ：11/12/07

出向先のプロジェクトの話。
テーブルに主キーが1つも設定されていませんでした。
しかも全テーブルに。
担当者に問い合わせたところ、
「主キー付けるとデータを入れにくくない？」
っていわれました。
しかも「そんなこともしらないの」っていわれました。
システムは無事に完成。
納品されて、今も動いてます。
でも、主キー無しです。
良いのでしょうか？

2 ：

(・∀・)ｰ!

3 ：

ユニークIDを別に管理して外部キーかもしれん

4 ：

See below:
CREATE TABLE PRIMARY_KEY_LESS_TABLE (id integer, data varchar(100));
見たーなーーー.

5 ：

それを発展させる気が無ければアリだと思う。

6 ：

きっとExcel大好きな会社なんだろ

7 ：

検索が糞遅そうだなあ・・・

8 ：

>>7
Joinとかしてたら最悪だね

9 ：

別にprimary key　がなくても、それほどすごいことはないと思うが。
確かに、１行単位での削除とかできないが、それは用途の問題だし。
uniqueでないindexでもべつにいいわけだし、
意味のない行番号ならつける必要ないんじゃない？

10 ：

たとえば、商品コードが商品テーブルの主キーに
なってないとしても、レコードの挿入時に商品コードの値が
テーブル中で重複しないようにプログラムがチェックする
ようになっていればいい。なぜなら、ユニーク指定なしの
インデックスでも検索できるから。
そんな調子で全テーブルをユニークキーなしで開発する
ことは可能ではある。
でもそれって、本来はＤＢＭＳがやるはずの重複検査の
仕事をプログラムがやっているってことで、開発や保守で
必要以上の苦労をしょいこむことになるな。そうでなくても、
プログラムのコードをよく読まなければテーブルの関係を
理解できないってことになってこれはつらい。
データベースの構造を見ただけでどんなシステムかがわかる
くらいでないと、開発でも保守でもラクできないよね。

11 ：

＞「主キー付けるとデータを入れにくくない？」
これが全てをものがたってるな

12 ：

そんなに深刻なるな1よ
1の担当者はエクセルシートの代わりにDBを使いたかっただけなんだよ
なぜDBにしたかというと、そのほうが儲かるからだろう
実際、どうでもいいようなシステムなんだろ？

13 ：

カード型DBの発想から来てるんだろうね＞主キーなし
「カード1枚でユニークになってるだろ！」とゆー半端ユーザーの声が聞こえてきそうだ（涙

14 ：

>>1
かならず主キーが必要と考えている>>1は問題あるぜ
主キーが何なのかを理解できているのか?
>>13
カード型DBって懐かしいな(w
Ninjaを思い出してしまった。

15 ：

必要と言うか、パフォーマンスや整合性考えたら普通はつけるわな。
多分、必要と言っている分野の人はOracle派で、
どうでもいいと言っている人はMySQLとかMSSQLとか使いだと思う。

16 ：

PostgreSQLですが、いざとなったらoid使うんでどっちでもいいけど
入れにくい、という理由でキーを廃止するのは違うと思う・・・

17 ：

藻前ら Codd 博士の RDB 理論について勉強しなおせ。
理論上 RDB には主キーなど必要無い。
但し、行全体でユニークにはなっていないといけない。
同じ内容の行が二つあったら駄目なところが Excal と違うとこ。

18 ：

Excal って何だ。ｗ

19 ：

主キーがあるのと無いので全然検索速度変わるDBMSもめずらしかないだろ。

20 ：

メインキーなくてもmultiなindexでも検索速度かわらないDBもめずらしくないしなあ。
１はちょっといいすぎかと。やっぱ用途次第だと思うな。
「indexのないDB」だったらすごいけどな。

21 ：

常にテーブルスキャンするDBもあるんでないかい？

22 ：

どっちかというと、すべてのテーブルでメインキーが必要ない
データ設計ってどういうんだよ・・のほうが突っ込むとこだな。
正規化スレ的だけど。JOINとかしないんだろうなー。

23 ：

>>17
主キーが行全体になっていればいいんだな(w

24 ：

理論的にどうなのかはよく知らないけど、
要するに主キーを用いないで「他人にわかりやすい、
保守しやすいシステム」になるかどうかだ。
そういう意味ではどうなんだろう。

25 ：

更新や削除等で、ある1行を特定するときどうやってんだろう

26 ：

順次処理しか行わないテーブルなら別に主キーが無くてもいいように
思うが。
アプリケーションログとかね。

27 ：

>>25
全部のカラムをwhere条件に指定する。ｗ

28 ：

>>24
＞テーブルに主キーが1つも設定されていませんでした。
＞しかも全テーブルに。
こんなシステム引継ぎさせられたら、暴れちゃう（ｗ
多分、1年ぐらいしたらレスポンス悪い部分がぼろぼろ出てきて
悲しくなるんだろうなぁ。。。

29 ：

>>26
それをDBで管理するのは・・・どうよ？

30 ：

>>29
うん。テキストファイルやCSVに書き出せとか言われそうだけど、
ファイルオブジェクト使うのが面倒とか、バックアップ・リカバリ
などはDBMSで一元管理したいとかね。

31 ：

>>28
まぁでも主キーを設定したからって、それを使ってない不毛な
アプリをこれまで結構見てきたよ。
あくまで一意制約としてのみしか扱ってない。
実行計画みたら、全部テーブルスキャンとか。

32 ：

>>31
あるある（ｗ
そういえば、もっと凄いのも見たことあった。。。
1レコードinsertするのに6時間くらいかかってたシステム。。。
ヽ（｀Д´）ﾉ 思い出したくないよー。

33 ：

主キーがＧＵＩＤだったっていう何の為のキーなんだか分からんのも見たことはあるな(w

34 ：

>>32
どうやったら、そんなに時間が掛かるんだ？
インデックスが全カラムにあるとかか？

35 ：

>>32
OLTPなら間違いなくSessionTimeoutだな(藁

36 ：

>>35
ユーザが痺れを切らしてタイムアウト、つか、ｺﾞﾙｧｰされるのが早い。

37 ：

ｺﾞﾗｧされて呼ばれたのが、(作った訳でもないのに)僕な訳で・・・。
で見てみると、Oracleなのに表領域もテーブルもサイズ指定しないで
作成されてて、自動拡張し放題。
その上、データベースのディスクに通常のデータ(excel,waord,access等)
も一緒に放り込んでるので、フラグメンテーションし放題。
(´-`)．。oO（あぁ、oracleもmsaccess見たいに使うとこうなるのか・・・）
とか思いつつ。
動作しているサーバマシンを見るとメモリが128M。( Д )　　ﾟ　　ﾟ
「もう、お願いしますからマシン買ってください」と言ってサーバを新しいのにして貰った。
＃余談：1データ登録するのに帰宅ときに登録、翌朝出社したら登録終了という
＃使い方をしてたらしい。。。
DBがどうとか、言う話じゃないっすね。スレ汚しすまんです。

38 ：

データ「1件」じゃなくてほんとに1レコード登録するのにそんなに
時間がかかってるとしたら、主キーがないとかディスクがどうだとか
じゃあ説明つかないような気もするが。
実はビューだったとか、挿入トリガーが仕掛けてあったとかじゃない？

39 ：

＞実はビューだったとか、挿入トリガーが仕掛けてあったとかじゃない？
ぃゃ、そんな上等な話じゃなかったと思います。。。たぶん。。。
常時スワップしててディスクアクセスしっぱなしで、
メモ帳すらろくに動かん状態だったので。
oracleのエクステントも１Mくらいのが100超えてたし。

40 ：

>>39
Oracle 9i でメモリ128だとありえない話では無いな。。
それに何も考えずにOracleフルインスコしてるんだろ？ 必要無いものまで。

41 ：

>>37
＞＃余談：1データ登録するのに帰宅ときに登録、翌朝出社したら登録終了という
＞＃使い方をしてたらしい。。。
そんなんで運用できるとはどんなアプリなんだ？？

42 ：

だんだん登録が遅くなって、昼間は登録禁止、から
運用ルールが出来上がっていったんだろうなｗ

43 ：

>>1のDBがAccessなら許すｗ
お客「検索が遅いんだけど速くしてくれない？？」
担当「え？主キーってなんですか？？」
のちの保守で地獄を見そうですな・・・。
１．素人は主キーを設定してはならない

44 ：

>>43
Access使ってるシステムなんて企業の中枢システムなわけが無いから
テキトーでいいんです。テキトーで。

45 ：

>>44
いや、中小の工場系では意外とマジに基幹だったりする・・・
納めたことありますもの。

46 ：

>>45
あっ。。うちも400万ぐらいの仕事であったかも。。
新人が中心に作ってたな。
ﾊﾞｯｸｱｯﾌﾟ･ﾘｶﾊﾞﾘの立案も出来ないしﾃﾞｨｽｸ飛んだら
終了ですみたいなことを平然と言ってのけたらしい。

47 ：

>>46
日次しかできないけど、バックアップ(コピー)ぐらいはしてるよね？
ウチは他に圧縮？(名前忘れた)も日次でしてるよ。

48 ：

>>47
ごめん。直接携わってないからそこらへんはよくわかりません。
日次バックアップくらいはやってのかなぁ？
でも完全なスタンドアローンシステムでサーバなんてのは
無かったと思うし、業務終了したら多分パソコンの電源落としちゃう
運用だからバックアップなんてしてないかもね。

49 ：

>>48
ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
ACCESSは業務に使うと定期的に壊れますた。

50 ：

>>15
主キーがなくても通るのはODBC経由の話で、MSSQL自体は主キーがないと許さんよ。

51 ：

>>50
いや、主キーがなくてもテーブル自体は定義出来るし、
ODBCでもアクセス出来るでしょ。

52 ：

>>51
オラクルも主キーなしでテーブル作れるんだが…

53 ：

主キー無しでテーブル作れないRDBってあるのか？
警告が出るのは見たことあるけど

54 ：

>>53
無いね。俺の汁限り。

55 ：

タコな質問ですいませんが、
主キーと、ユニークインデックスってどう違うのでしょうか?

56 ：

　（健康体）　　（喘息）

1.（神が喘息であるかないかを決める）
　　Y　　　　　　　　I
2.喘息でない人　　喘息の人は
は体力がある　　　体力がない
Y I
3.　　　　　　　　行動力、
　　　　　　　　　五感（嗅覚）が鈍り感性が変化
　　　　　　　　　する
　　Y　　　　　　　　I
4.神は異常な感性の人間は本来人に迷惑をかけるから外に出てはいけないと思っている。
Y I
5.変化なし　　　　アトピーになる
Y I
6.正常な感性　　　外に出なくなりさらに異常な感　　　　　　　　　性になる
Y I
7.正常な人間 　　 異常な人間（レッテル）

57 ：

Y I
8. 死
　　Y　　　　　　　　I
9.　　　　　　来世
Y I
10.神は異常な人間は人に迷惑をかけるので行動を抑制する必要がある
Y I
11.神は異常な人間は人に迷惑をかけるので行動を抑制する必要があると思っている。
Y I
12.神が喘息であるかないかを決める
　　Y　　　　　　　　I
13.喘息でない　　　喘息である
　　Y　　　　　　　　I
　　　　　1.に戻る
神は事態の収拾に必死、頑張れよー。

58 ：

アトピー性皮膚炎の治し方
行動力=ガッツ=体力
アトピー性皮膚炎の患者は、
感覚の鈍い人間が多い。
それはなぜか。
幼少期喘息になるから、
体力がつかないため、
五感が弱るからである。
解決方法は、
五感を強くしてやればいい。
体力をつけることですぐに五感が正常になり、
行動力も湧くのである。
五感が正常になり、体力もつけば、
アトピー性皮膚炎も不思議と消えることが多い。

59 ：

>>55
プライマリキーの設定ができないDB（古いバージョンのSQL Serverなど）
を利用している場合、ユニークなインデックスを作成して、
プライマリキーと同等の効果を得ていた。
ちなみに
主キーとは
「表の行を唯一に識別できる列または列の組」のことで、
主キーの列にNULLを入れることは可。
プライマリキーの列にNULLを入れることは不可。
1が言っている主キーとは、おそらくプライマリキーのこと。
ユニークインデックスも主キーとして扱うことは可能。

60 ：

>>59
昔は知らんが今は主キーとプライマリキーは同義だろ。

61 ：

55が使っているDBをおしえなさい。

62 ：

>>60
同義とはいえないな。
プライマリキーとは主キーに設定するものだ。
プライマリキーがない場合は、ユニークインデックスで代用しても可
ということだ。

63 ：

Primary KeyはUNIQUE + NOT NULL

64 ：

日本語と英語で同じ意味なのに違うのかよ・・・
言語そろえてくれー

65 ：

>>60>>64
昔のことを知らない若造なのだが、
昔は「主キー」と「Primary key」が別物だったのか?
単なる訳語じゃないの?
教えろ。

66 ：

主キー ＝ Primary key (主なるキー) だが。

67 ：

>>62
今時、そんな設計する奴がどうかしてる。
ユニークインデックス設定する前にプライマリキーを設定しろ。

68 ：

主キーはＤＢ設計上の概念
INDEXはDB操作上の概念。
ドメインが違う。んでぇ、主キーが無いって事はRDBではない事だ。

69 ：

>>68
>主キーはＤＢ設計上の概念
つまりはそういうことなんだろうな

70 ：

>>68
＞んでぇ、主キーが無いって事はRDBではない事だ。
それは違ぁ〜〜〜〜う。

71 ：

>>70
なぜだ？

72 ：

RDBのシステムにのっけりゃなんでもRDBというわけでもないな

73 ：

>>71
嫁！ 主キーはRDBの必須条件ではない。
http://www.amazon.co.jp/exec/obidos/ASIN/4621042769/qid=1070631476/sr=1-1/ref=sr_1_2_1/250-0170725-0347471

74 ：

1.単純な表には、行の重複(同一な値)は許されない。
2.行が同一であることを見分ける属性の組み合わせを候補キーという
これは複数あってもよい。
3.候補キーのうち、一つを主たるものとするとき、これを主キーという。
RDBMSとしては、主キーがなくてもよいが、候補キーは必ず必要。
(内容が全く同一な行は複数存在してはいけない)
・・・ただ、それは理論的な話で、各社のRDBMSの実装としては、
内容が同一な行を追加できたりする。
現在、RDBMSとして売られているもので、完全なRDBMSという
(理論を完全に実装している)ものはない。

75 ：

＞(内容が全く同一な行は複数存在してはいけない)
そ、これがＲＤＢの必須条件。
でも、主キーが無いテーブルは激しく使いにくいわーなぁ〜。

76 ：

>>74
違うね。RDB理論では。
内容が全く同一な行は複数存在していけない。
かつその行の一意性を定めるのが主キーだ。
つまり、RDB理論では一意性が担保されるなら
日付時間（OSと同等の分解能）商品名　こんなテーブルも許可される。
テーブルの行全体が主キーなのだ。
これを誤解してそんな風に書いたのだろう。

77 ：

であるから、主キーの一意性が担保されるのなら、
主キーにインデックスを張る必要は無いし、事実
そーゆう事はパフォーマンスの為にやることも有る。
RDBMSが主キーをどのように扱うかによるが。

78 ：

>>76
修正、
×かつその行の一意性を定めるのが主キーだ。
○かつその行の一意性を定める最小のカラム構成が主キーだ。
この方が分かり易い

79 ：

>>主キーにインデックスを張る必要は無いし、事実
>>そーゆう事はパフォーマンスの為にやることも有る。
さっぱり理解できん。

80 ：

研修行かせてもらえなかったので理論はよくわかりませんが。
テーブルにもいろいろあり、
マスター系のテーブルには主キーは必要かと。
データ系のテーブルには、インデックスを張っています。
（インデックスが壊れたときのため、ジャーナルナンバーと言う枠で最低限のデータのINDEXは保っています。）
それでもINDEXがないと（DATA量5Gぐらい：TXTベース）50％ぐらい処理能力は落ちます。
今後の為、意見等ございましたらお聞かせください。（当方SYBASE）

81 ：

別にＰＫがない表があってもおかしくないでしょう？
単に全カラムを同じように更新したいだけなのでは？
そもそも、ＰＫとは制約のひとつでしょ？　決して必須ではないはず。
もっと柔軟に考えたら？ >>1

82 ：

RDBとRDBMSを分けて考える様に。
主キーはRDBなら必須。主キー制約を設定するかは任意。

83 ：

>>81
データを入れにくい、という理由であえてPKを設定しないんだぜ？

84 ：

履歴のデータを格納するテーブル

85 ：

現場、現場、実務、実務ってゆうひと多いですが、
理論をわかった上でゆってほしいものです。

86 ：

>>85
その心は？ただの釣り？

87 ：

>>86
データを入れにくいからPKの設定しないような人たちの事だと思う。
てか、PKの設定をするとデータ入れにくいようなDBの設計をする人
の事だと思う。

88 ：

入れにくいってどういうことだろう
データがかぶって重複エラーがうっとーしーのか
重複しない値を出すのがめんどーなのか・・

89 ：

>>88
おそらく前者
おれも前に「は？」っていうテーブルにでくわしたことがある
下のようなデータをいれるテーブルで、
--------------
顧客　訪問日
--------------
A社　20030101
A社　20030110
B社　20030101
B社　20031010
C社　20030201
--------------
で、テーブル設計書には「顧客」がPKとなっていた。
担当者（上司）に「これは無理です！」って訴えたら、
「無理とかいうんじゃない！やってみなければわからんだろ！！」
って。。
わかるだろ。

90 ：

続き
このときは、PKの設定やめました。
上司の言う通り、やってみなくちゃわからないってことですね。

91 ：

( ；ﾟДﾟ)ﾎﾟｶｰﾝ

92 ：

ﾜﾗﾀ

93 ：

>>90
念のため聞くが、この場合はどのような切り方が正しいと思う?

94 ：

>>89
ネタとしか思えん。

95 ：

>>93
訪問履歴みたいなトランザクション系のテーブルと仮定したら
シーケンス番号(PrimaryKey)+顧客コード+訪問日
ってとこかな？

96 ：

>>95
漏れなら
顧客コード＋訪問日＋枝番でPrimaryKeyかな。

97 ：

このテーブルはいい例だ。シーケンス番号をPrimaryKeyなんだが、
全てのDBとのリンクは顧客コード中心場合によっては訪問日
なんて場合、PrimaryKeyに一意制約を付けて、顧客コードに
そのRDBMSで一番早いKeyを設定する（物凄く古いRDBMSだと重複可の主キーだったりする）

98 ：

>>97
もちつけ
面白そうなんでもう少し分かりやすく説明してYO

99 ：

>>97の意訳を試みると
PrimaryKeyには一意制約（重複しない条件）ために使用し、検索のスピード
を上げるためのキーとしては顧客コードの欄を用いる。その際に用いる値は
全てのテーブルで利用しかつ検索スピードが早くなるコードを考える。
こんなとこでOK？

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
17: 何故データベース設計は軽視されるのか？ (471)
18: ADO.NETの質問・雑談スレ2 (388)
19: データベースを略してデーベーと呼ぶスレ (96)
20: Debian に美しいフォントを追加したい (12)