関係DBの主キーはなぜ必要なのでしょう？

Question

前提

MySQL以外あまり知らないので、MySQLを前提とします。

聞きたいこと

リレーショナルデータベースの主キーはなぜ必要なのでしょう？

テーブルには主キーを設定することができますが、主キーを設定しないテーブルも作ることができます。
ユニーク制約や外部キー制約によって、テーブル内で一意にレコードが特定できるキーが存在する場合、主キーはなくても問題ないのでしょうか？

補足

個人的には、テーブルには主キーが設定されているのが当然だと思っていますが、
なぜ設定されていて当然なのかうまく説明できないため、本質問をさせていただきます。

7/15 3:10追記

DB設計の概念的な意味での主キーと、
実際のテーブルの設定としての主キーの二つの意味があると思ったので、補足します。

概念的には主キーが存在するテーブル（非Nullableかつユニーク制約があるカラムが存在する）について、
テーブルの設定として主キーを設定しないメリットはありますか？ というのがお聞きしたい内容です。

Answer 1

概念的には主キーが存在するテーブル（非Nullableかつユニーク制約があるカラムが存在する）について、

テーブルの設定として主キーを設定しないメリットはありますか？ というのがお聞きしたい内容です。

ログなんかはこれに該当するんじゃないでしょうか、無駄な制約もインデックスもいらないと思うので。
例えば特に参照する予定の無い、ログを溜め込む事だけが目的のテーブルには主キーつけなくてもいいと思います
テーブル自体は一定期間単位（一年とか）で分けておいて、既定の期間が過ぎたら圧縮するなり削除するなししていく
税務署対策に過去５～７年分の取引の記録を取っておくようなものに近いかも
万が一記録の提出を求められたらそのままログを提出、みたいな
外部キーはデータ次第ですね。他のテーブルと合わせて整合性が取れている必要があるかどうかなので、整合性が取れてる必要の無いログなら外部キーもいらない

もちろんそのログを元にデータを集計したり統計取ったりとかする予定があるならキーはあった方がいいですね

実際にこれらの用途をした事は無くて今思い付くものを回答しただけなので、他にも色々パターンあるかも

Comments

[zackey2]

> ログを溜め込む事だけが目的のテーブルには主キーつけなくてもいいと思います
>税務署対策に過去５～７年分の取引の記録を取っておくようなものに近いかも
たしかに、そういうケースは主キーいらないかもしれないですね。
> もちろんそのログを元にデータを集計したり統計取ったりとかする予定があるならキーはあった方がいいですね
納得です。
ただ、キーがないと、レコードをテーブルから全部ぶっこ抜く（あるいはOFFSETとLIMITで指定範囲を取り出す）
しかないから、あとからデータを取り出したいケースが出た時に、担当者に恨まれることになりそうだなと思いましたw

Answer 2

概念的には主キーが存在するテーブル（非Nullableかつユニーク制約があるカラムが存在する）について、

テーブルの設定として主キーを設定しないメリットはありますか？ というのがお聞きしたい内容です。

外部からの取込データを一時的に格納するテーブルなどは、主キーとはせず候補キーとすることで一旦は取り込めるというメリットがあります。
※マスターとチェックするとかがあると一旦取り込んでからの方が効率が良かったりしますので。

主キーが設定されるのは、DBMSにとって効率が良いという事も当然ありますので、使い捨てするようなデータでない限り、基本的に設定するものと考えておいた方が良いものです。

尚、質問されている主キーはナチュラルキーを指しているものと思いますが、主キーをサロゲートキーにするかナチュラルキーにするかは、状況に応じてですけど。

Answer 3

ユニーク制約や外部キー制約によって、テーブル内で一意にレコードが特定できるキーが存在する場合、主キーはなくても問題ないのでしょうか？

そのような列が存在するなら、それを主キーに設定する、という選択肢もあるかと思うのですが。

ただし、フレームワークの都合上、特定の形の主キーが必要になるような状況も考えられますし、複合主キーも扱いづらい面はあります。

Answer 4

主キーはレコードを特定するために使います
したがって主キーはユニークでnullを許しません
データテーブルに置いて主キーはauto_incrementなどそのコード自体に意味のない
ものを指定するのも普遍性が重要だからです。

可能な限りすべてのテーブルに主キーは設定するようにしてください

Answer 5

社員マスターで考えてみましょう。同性同名って珍しくありません。総務部の山田太郎さんと営業部の山田太郎さんをいちいち使い分けるのは大変ですし、他の部門に移動したら、結婚などで名字が変わったら、って情報を加味して山田太郎さんの社内での移動情報を管理するとシステムはとっても複雑になります。出張の旅費精算、家族手当などもろもろのシステムでどの社員かをきちんと特定できないと経理部が怒り出します。
そこで、社員IDなどの入社から退社までずっと変わらずにその人を特定できる主キーを持つと、主キーだけで社員を特定できてシステムもかなりシンプルになります。

Comments

[zackey2]

それってユニーク制約でいいですよね？ 強いていうなら非Nullableになっていれば。

[Orlofsky]

not null でユニークであれば何でもありと、一意(ずぅーーと同じ値で)に管理できるというのはちょっと違います。
プライマリキー(主キー)とユニークキーの違い https://www.shift-the-oracle.com/constraint/

[zackey2]

主キーは変更されにくいカラムを使った方がいいというのは納得しました。

主キーを設定するメリットは、
・not nullでユニークであるというDBMSの機能としての制約
・そのテーブルのキーで代表的なもの　という印

に加え
・「変更しない項目の集合であることが望ましい」　という思想
があると言えそうですね。

つまりは、クソみたいな設計のテーブルが作られることを避けることができる。
ということかなと思いました。

Answer 6

--->ユニーク制約や外部キー制約によって、テーブル内で一意にレコードが特定できるキーが存在する場合、主キーはなくても問題ないのでしょうか？

やり続けるとテーブル数は少なくて済むと思いますが、なんだかんだでカラムが増えやすくなると思います。そうなると、保守性(メンテナンスなど)という観点からあまりよくない設計方法になると思います。人のミスも増えますし...。なので、外部キーを設定することによってリレーションを構築し、データ間のつながりを直感的にわかりやすくするのが良いのではないかと思います。

昔、以下のURLで直感的に理解できたので、もし良かったら参考にしていただければと思います。
https://www.accessdbstudy.net/entry/20141020/p1#02000

Comments

[zackey2]

ご回答ありがとうごあいます。
> やり続けるとテーブル数は少なくて済むと思いますが、
テーブル数が少なくなる　というのがちょっとわかりません
すません、質問がわかりづらかったと思うので修正します。
テーブルの設定として外部キーは設定するが、主キーを設定しない場合について質問しています。

[mikkame]

テーブル数が少なくなる＝正規化しないって意味では？
主キーに関しては関係ないと思います

Answer 7

主キーは必要ではありません。
ご自身で書いている通り、

主キーを設定しないテーブルも作ることができます。

これが可能なので。（必要、なら強制になるはずです）

「データを一意に識別できるキー」は複数の候補が存在する可能性があり、テーブルによって参照するものがバラバラだと困るので、代表として１つに定めるもの、と思えばわかりやすいんじゃないでしょうか。

Comments

[zackey2]

ご回答ありがとうございます。
絶対必要ではないが、混乱を避けるためあった方がいい　ということですね。

Answer 8

主キーは特定や重複問題が発生する等用途がある場合のみ、必要ならば付ければよいです。ので、貴方の感覚は正しいと思います。忖度して「主キーがあって当然」と思う必要はないと思います。

SQLアンチパターンという書に、アンチパターンとして「とりあえずIDを付ける」というのを紹介する以下の章があります。

3章　IDリクワイアド（とりあえずID）
    3.1 目的：主キーの規約を確立する
    3.2 アンチパターン：すべてのテーブルに「 id」列を用いる