GUIDなしでNatural ID列を使用する必要がありますか？

Question

2つの外部キー列を持つ表の主キーを組み合わせても、一意にする必要はありませんか？したがって、新しいid列（Guidまたはint）を追加しないでください。

これには否定はありますか？

Answer 1

はい、完全に問題ありません。何故なの？複合主キーの欠点は、それが長くなる可能性があり、アプリケーションの観点から一行を一意に識別することが難しいことです。しかし、2つの整数列（特にジャンクション・テーブル）では、それは良い方法です。

Answer 2

"ok"の定義には、はい。この交差テーブルにフィールドを追加するつもりがない限り、それは問題ありません。ただし、フィールドを増やす予定がある場合は、IDフィールドを持つことをお勧めします。それはまだ良いですが、それを考えに来るが、より扱いにくいかもしれません。

もちろん、ディスク容量には重大なプレミアムがあります。

Answer 3

データベースの教科書を見ると、そのような表が大量に見つかるでしょう。これは、n対m関係を定義するデフォルトの方法です。たとえば：あなたはそれを主キーとして定義を控え、代わりにUNIQUE制約を持つ通常の指標として、それを作成することがありますので

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

は意味的に、article_authorは新しいエンティティではありません。

Answer 4

はい、私は同意します。「OKの定義」はOKです。しかし、このコンポジット・プライマリ・キーをどこかから参照する（つまり、それを外部キーに移動する）と、すぐにNG（Not Good）と呼ばれます。

Answer 5

ナチュラルと人工のプライマリキーは、広く議論されている問題の1つであり、IMHOではそのポジションが固まっているように見えます。

私の意見では、開発者が両方の欠点を回避する方法を知っている限り、どちらも問題ありません。自然な主キー（複合または単一列のいずれか）は、重複行がDBに追加されないことをより確実に保証します。人工の主キーでは、最初にレコードがユニークであることを確認する必要があります（主キーとは対照的に、人工的なものは常にユニークです）。これを達成する1つの効果的な方法は、レコードを一意にするフィールドに一意または候補インデックスを持たせることです（たとえば、主キーの候補となるフィールド）。

一方、人工の主キーは簡単に結合できます。 1つのフィールドから1つのフィールドへの結合で関係を作ることができます。コンポジット・キーを使用すると、SQL文の作成者は、結合に含めるフィールドの数を把握する必要があります。