sql - GUIDなしでNaturalIdentity列を使用する必要がありますか？

Question

組み合わせて一意でなければならない2つの外部キー列を持つテーブルの主キーを定義しても大丈夫ですか？したがって、新しいID列（Guidまたはint）を追加しませんか？

これにはマイナス面がありますか？

Answer 1

はい、完全に大丈夫です。なぜだめですか？複合主キーの欠点は、長くなる可能性があり、アプリケーションの観点から単一の行を一意に識別するのが難しい場合があることです。ただし、いくつかの整数列（特にジャンクションテーブル）の場合は、これをお勧めします。

Answer 2

自然対人工の主キーは、広く議論される問題の1つであり、私見では、議論は立場が固まるのを見るだけのようです。

私の意見では、開発者が両方の欠点を回避する方法を知っている限り、両方が機能します。自然な主キー（複合列または単一列）は、重複する行がDBに追加されないことをほぼ確実にします。一方、人工主キーでは、最初にレコードが一意であることを確認する必要があります（人工である主キーとは対照的に、常に一意です）。これを実現する効果的な方法の1つは、レコードを一意にするフィールド（たとえば、主キーの候補を作成するフィールド）に一意のインデックスまたは候補インデックスを設定することです。

一方、人工の主キーを使用すると、簡単に参加できます。関係は、単一フィールドから単一フィールドへの結合で作成できます。複合キーを使用する場合、SQLステートメントの作成者は、結合に含めるフィールドの数を知っている必要があります。

Answer 3

「ok」のいくつかの定義については、はい。この交差テーブルにフィールドを追加するつもりがない限り、それで問題ありません。ただし、より多くのフィールドを作成する場合は、IDフィールドを作成することをお勧めします。それはまだ大丈夫です、考えてみてください、しかしもっと厄介かもしれません。

もちろん、ディスク容量が非常に重要でない限り！

Answer 4

データベースの教科書を調べると、そのような表がまとめて見つかります。これは、n対mの関係を定義するデフォルトの方法です。例えば：

article = (id, title, text)
author = (id, name)
article_author = (article_id, author_id)

意味的には、article_authorは新しいエンティティではないため、主キーとして定義するのを控え、代わりにUNIQUE制約を使用して通常のインデックスとして作成することができます。

Answer 5

はい、同意します。「OKの定義」でOKです。しかし、この複合主キーをどこかから参照する（つまり、外部キーに移動する）と決めた瞬間、すぐにNG（良くない）になります。