- PR -

主キーについて

1
投稿者投稿内容
未記入
会議室デビュー日: 2005/04/13
投稿数: 1
投稿日時: 2005-04-13 21:40
アドバイスを下さい。
以下のようなテーブルがある場合主キーは必要なのでしょうか？
はじめはどのようなテーブルでも主キーを付けるべきだと考えていたため
1.のフィールドを意味もないのに態々付け、主キーに設定しました。

よろしくお願いします。


レコード数は一日2万件ほど増えていきます。

テーブルの構造
＜フィールド＞
1.SEQ
2.場所
3.部屋
4.席
5.購入品
6.購入金額
（SEQはシーケンスオブジェクトを使用して、一意に割り当てています。）

＜INDEX＞
A. フィールド1.に主キー
B. フィールド2. 3. 4. に複合ノンユニークキー
（検索をかける場合にこの項目を使用するため）

DBはORACLE９です。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-04-13 22:02
引用:

未記入さんの書き込み (2005-04-13 21:40) より:
以下のようなテーブルがある場合主キーは必要なのでしょうか？
はじめはどのようなテーブルでも主キーを付けるべきだと考えていたため
1.のフィールドを意味もないのに態々付け、主キーに設定しました。

必要。
主キーが無いとUpdate文を実行する必要が生じたときに泣きが入りません？OracleはROWIDがあるからまだ良いけど、ODBC経由でアクセスしている時など非常に困るはず。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2005-04-13 22:25
unibon です。こんにちわ。

引用:

未記入さんの書き込み (2005-04-13 21:40) より:
以下のようなテーブルがある場合主キーは必要なのでしょうか？

一般に、ログ(?)のようなテーブルには、主キーは付けなくても良いです。文書番号とかが付いているのならば、それを主キーにするのが普通でしょうが、文書番号にあたるようなIDを付けることが思い付かないようなテーブルならば、付ける必要はないでしょう。付ければ逆に冗長になってしまいます。

引用:

未記入さんの書き込み (2005-04-13 21:40) より:
はじめはどのようなテーブルでも主キーを付けるべきだと考えていたため
1.のフィールドを意味もないのに態々付け、主キーに設定しました。

このようなキーを人為キー(artificial key)と言います。上述のように、論理的な観点から言えば、なくても良いのですが、物理的にプログラムからアクセスする場合は、主キーがあったほうがなにかと便利です(SQL が書きやすい等)。プログラムの立場からすれば、とにかく付けておいたほうが無難です。ただ、このようなキーを付けるためには管理に手間がかかるのでそれとの引き換えになります。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2005-04-13 23:20
ツール等で、グリッド上でのデータ更新を行いたい場合とか、
主キーが必要になるケースもありますね。（あったら便利という観点）

論理的な設計という観点からは冗長で不要なものであっても、
実際にプログラミングを行ううえでは、
あった方が楽にプログラミングできるという場合もあります。
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-04-14 07:19
引用:
このようなキーを人為キー(artificial key)と言います。(中略)とにかく付けておいたほうが無難です。

人工キーを付けると実行性能を落とす可能性もあるので注意が必要。自然キーで一意性を確保できる場合には、(それが複合キーであったとしても)自然キーを主キーにするべきだと思います。

たとえば、データの抽出範囲指定は多くの場合ユーザーが画面から入力しますね。この入力値が、自然キーに該当することはありますが、人工キーに該当することはほとんどないと思います。(人工キーを画面から入力することは考えにくい。) 自然キー(主キー)に該当する場合は範囲スキャンで効果を発揮する可能性が高いですが、人工キーだとフルスキャンになってしまいます。

なので、私は人工キーには反対。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2005-04-14 09:37
unibon です。

引用:

未記入さんの書き込み (2005-04-14 07:19) より:
引用:
このようなキーを人為キー(artificial key)と言います。(中略)とにかく付けておいたほうが無難です。

人工キーを付けると実行性能を落とす可能性もあるので注意が必要。自然キーで一意性を確保できる場合には、(それが複合キーであったとしても)自然キーを主キーにするべきだと思います。

ちょっと書き足りませんでしたが、人工キーを付けたほうが良い、ということではないです。主キーを付けないよりは、人工キーであっても主キーを付けておいたほうが、プログラムから使う分にはそのほうが無難で良い、ということを書きたかったのです。

プログラムから、行を特定する目的で、主キーがあればそれを使い、なかったらインデックスを使う、ということをやることがよくあります。でも、論理的な観点からすればそのためにキーやインデックスを使うのは本来の目的とは違うので付けないほうが良いのですが、でも、付けてないばかりにプログラムが複雑になったり、パフォーマンスが悪くなったりするのもしゃくです。RDB にアクセスする手段が SQL とその結果セットをカーソルで走査するというやりかたに縛られているためかもしれません。
あんとれ
ぬし
会議室デビュー日: 2004/01/14
投稿数: 556
投稿日時: 2005-04-14 10:25
引用:

未記入さんの書き込み (2005-04-14 07:19) より:

人工キーを付けると実行性能を落とす可能性もあるので注意が必要。自然キーで一意性を確保できる場合には、(それが複合キーであったとしても)自然キーを主キーにするべきだと思います。


主キーが５〜６カラム以上あって、しかもそのテーブルが親テーブルとなっている場合、物理設計の段階では代替キーも検討すべきだと思います。でないと、その親テーブルに従属する全ての子テーブルに、リレーションを張るための外部キーを５〜６カラム以上もセットする必要が出てしまいますから。さらに、そこにインデックスを張るともなれば領域の無駄や性能劣化にもつながりますし。

[ メッセージ編集済み 編集者: あんとれ 編集日時 2005-04-14 10:32 ]
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-04-14 12:19
引用:
人工キーを付けたほうが良い、ということではないです。主キーを付けないよりは、人工キーであっても主キーを付けておいたほうが、プログラムから使う分にはそのほうが無難で良い、ということを書きたかったのです。

そういうことであれば納得です。

引用:
主キーが５〜６カラム以上あって、しかもそのテーブルが親テーブルとなっている場合、物理設計の段階では代替キーも検討すべきだと思います。

うーん。微妙ですね。私はそれでも 5〜6列の複合主キーを付けますよ。子テーブルにリレーションを張るために 5〜6列持たなければならないというは記憶領域ではデメリットだけど、その子テーブル単体での見通しが良くなるというメリットもあるので。自然キーというのは、その値そのものに意味を持っているわけだから、親テーブルと結合しなくても子テーブルだけで意味が取れるようになる。
1

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