すべてのテーブルに主キーが必要ですか？

データベーステーブルを作成していますが、論理プライマリキーが割り当てられていません。だから、私は主キーなしでそれを残すことを考えていますが、私はそれについて少し罪悪感を感じています。したほうがいい？

すべてのテーブルに主キーが必要ですか？

短い答え：はい。

長い答え：

• テーブルを何かで結合できるようにする必要があります
• テーブルをクラスター化する場合は、ある種の主キーが必要です。
• テーブルのデザインに主キーが必要ない場合は、デザインを考え直してください。おそらく、何かが足りないでしょう。同一の記録を保持するのはなぜですか？

MySQLでは、明示的に指定しなかった場合、InnoDBストレージエンジンは常に主キーを作成するため、アクセスできない追加の列が作成されます。

主キーは複合にすることができることに注意してください。

多対多のリンクテーブルがある場合は、リンクに関係するすべてのフィールドに主キーを作成します。したがって、1つのリンクを説明する2つ以上のレコードがないことを確認します。

論理的な整合性の問題に加えて、ほとんどのRDBMSエンジンは、これらのフィールドを一意のインデックスに含めることでメリットを得ます。

また、主キーには一意のインデックスの作成が含まれるため、それを宣言して、論理的な一貫性とパフォーマンスの両方を実現する必要があります。

一意のデータに一意のインデックスを常に作成する必要がある理由については、私のブログのこの記事を参照してください。

• インデックスを一意にする

PS主キーを必要としない非常に特殊なケースがいくつかあります。

ほとんどの場合、パフォーマンス上の理由から、インデックスを持たないログテーブルが含まれます。

主キーは常に最善です。このようにして、最初の正規形を満たし、データベースの正規化パスに沿って続行することができます。

他の人が述べたように、主キーを持たない理由はいくつかありますが、主キーがあればほとんどは害されません

主キーなしでテーブルを作成したときはいつでも、テーブルは必要ないと考えていたので、戻って1つ追加してしまいました。次に、主キーとして使用する自動生成されたIDフィールドを持つ結合テーブルも作成します。

いくつかの非常にまれなケース（多対多のリレーションシップテーブル、または大量のデータの一括読み込みに一時的に使用するテーブル）を除いて、私はこう言います。

主キーがない場合、それはテーブルではありません！

マーク

このテーブルを他のテーブルに結合する必要がありますか？レコードを一意に識別する方法が必要ですか？答えが「はい」の場合、主キーが必要です。データが、顧客である人々の名前を含む顧客テーブルのようなものであると想定します。このSally SmithがSally Smithと異なるかどうかを判断するためにアドレス、電子メール、電話番号などが必要であり、その人物が複数の電話を持つことができるため、その情報を関連テーブルに保存するため、自然なキーがない場合があります。 、メールなど。サリー・スミスがジョン・ジョーンズと結婚し、サリー・ジョーンズになったとします。テーブルに人工キーがない場合、名前を更新すると、結婚して名前を変更したのに、7つのSally SmithsがSally Jonesに変更されました。

あなたはあなたが自然な鍵を持っていないと言っているので、一意にするためのフィールドの組み合わせもありません。これは人工的な鍵を重要にします。

自然キーがない場合はいつでも見つかります。人工キーは、データの整合性を維持するための絶対必要です。自然キーがある場合は、代わりにそれをキーフィールドとして使用できます。しかし、個人的には、自然キーが1つのフィールドでない限り、私は自然キーの人工キーと一意のインデックスを好みます。入れないと後悔します。

追加するだけで、後で追加しなかったときは残念になります（選択、削除、リンクなど）。

すべてのテーブルにPKを設定することをお勧めしますが、必須ではありません。ほとんどの場合、必要に応じて、一意のインデックスやクラスター化インデックス（PKかどうかにかかわらず）が必要になります。

Books Online（SQL Server用）の主キーとクラスター化インデックスのセクションを確認してください。

" PRIMARY KEY制約は、テーブル内の行を一意に識別する値を持つ列または列のセットを識別します。テーブル内の2つの行が同じ主キー値を持つことはできません。主キー内の列にNULLを入力することはできません。主キーとして列整数、小さなを使用することをお勧めします。各テーブルに主キーを有するべきである。主キー値として適格列または列の組み合わせを候補キーと呼ばれます。」

しかし、これもチェックしてください：http : //www.aisintl.com/case/primary_and_foreign_key.html

提案された回答に同意しません。簡単に言えば、いいえです。

主キーの目的は、別のテーブルとの関係を形成するために、テーブルの行を一意に識別することです。従来、この目的のために自動インクリメントされた整数値が使用されていますが、これにはバリエーションがあります。

ただし、たとえば時系列データのロギングでは、そのようなキーの存在が単に必要でなく、メモリを占有する場合があります。行を一意にすることは単純に...必要ありません。

小さな例：表A：LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

主キーは必要ありません。

表B：ユーザー

Columns: Id, FirstName, LastName etc. 

LogDataテーブルの「外部キー」として使用するために必要な主キー（Id）。

.NETでgridviewの特定の機能を使用するには、gridviewがどの行を更新/削除する必要があるかを知るために主キーが必要であることを知っています。一般的な方法は、主キーまたは主キークラスタを用意することです。私は個人的に前者を好みます。

それを将来の証明にするために、あなたは本当にすべきです。それを複製したいなら、あなたはそれを必要とするでしょう。あなたがそれを別のテーブルに参加させたいなら、あなたの人生（そして来年それを維持しなければならない貧しい愚か者のそれ）はとても簡単になるでしょう。

たとえ最初はまだその目的を考えていなくても、私は常に主キーを持っています。PKのないテーブルに最終的にPKが必要になることが何度かありましたが、後でPKを入れるのは常により困難です。常に1つ含めることには、もっと良い面があると思います。

私は、オフショア開発チームが作成したアプリケーションを維持する役割を担っています。元のデータベーススキーマの一部のテーブルにPRIMARY KEYSが含まれていなかったため、アプリケーションにあらゆる種類の問題が発生しています。だからあなたの貧弱なデザインのために他の人を苦しめないでください。テーブルに主キーを置くことは常に良い考えです。

つまり、いいえ。ただし、特定のクライアントアクセスCRUD操作では必要になることに注意してください。将来の証明のために、私は常に主キーを利用する傾向があります。

Hibernateを使用している場合、主キーなしでエンティティを作成することはできません。この問題は、プレーンなsql / ddlスクリプトで作成された既存のデータベースを使用していて、主キーが追加されていない場合に問題を引き起こす可能性があります。