すべてのテーブルに主キーが必要ですか？
データベーステーブルを作成していますが、論理プライマリキーが割り当てられていません。だから、私は主キーなしでそれを残すことを考えているが、私はそれについて少し罪悪感を感じている。するべきか？
すべてのテーブルに主キーが必要ですか？
簡単な答え：はい.
長い答え：
- 自分のテーブルを何かに結合できるようにする必要があります
- テーブルをクラスタ化したい場合は、ある種の主キーが必要です。
- テーブルデザインに主キーが必要ない場合は、デザインを再考します。おそらく、何かが足りないのでしょう。同一の記録を残すのはなぜですか？
MySQLでは、InnoDBストレージエンジンは、明示的に指定しなかった場合は常に主キーを作成するため、アクセスできない余分な列が作成されます。
主キーはコンポジットにすることができます。
多対多リンクテーブルがある場合は、リンクに含まれるすべてのフィールドに主キーを作成します。したがって、1つのリンクを説明するレコードが2つ以上ないようにします。
論理的な一貫性の問題に加えて、ほとんどのRDBMSエンジンはこれらのフィールドをユニークなインデックスに含めることから利益を得るでしょう。
また、主キーには一意のインデックスの作成が伴うため、それを宣言して論理的な一貫性とパフォーマンスの両方を実現する必要があります。
私のブログのこの記事を参照してください。なぜあなたは常にユニークなデータにユニークなインデックスを作成する必要があるのですか。
P.S。主キーが不要な非常に特別な場合がいくつかあります。
ほとんどの場合、パフォーマンス上の理由からインデックスを持たないログテーブルが含まれます。
ごくまれなケース（多対多のリレーションシップテーブル、または大量のデータを一括ロードするために一時的に使用するテーブル）を除いて、私は次のように述べます。
もし主キーがなければ、テーブルではありません！
マーク
主キーなしでテーブルを作成したときはいつでも、必要ではないと思ったので、戻って追加しました。主キーとして使用する自動生成されたIDフィールドを使用して、結合テーブルも作成します。
それを追加するだけで、あなたがしなかったときには後になってすみません（選択、削除、リンクなど）。
このテーブルを他のテーブルに結合する必要がありますか？レコードを一意に識別する方法が必要ですか。答えが「はい」の場合は、主キーが必要です。あなたのデータが、顧客である人々の名前を含むcustomerテーブルのようなものであると仮定してください。このSally SmithがそのSally Smithと異なるかどうかを判断するにはアドレス、Eメール、電話番号などが必要なので、自然な鍵はないかもしれません。 Sally SmithがJohn Jonesと結婚し、Sally Jonesになるとします。テーブルに人為的なキーがない場合、名前を更新すると、結婚して名前を変更したにもかかわらず、7人のSally SmithsをSally Jonesに変更しました。そしてもちろん、この場合、人為的な鍵なしで、どのSally Smithがシカゴに住んでいて、どれがLAに住んでいるかをどのように知っていますか？
あなたはあなたが自然な鍵を持っていないと言います、従ってあなたもユニークにするために分野のどんな組み合わせも持っていません、これは人工的な鍵を重要にします。
私は自然の鍵を持っていないときはいつでも見つけました、人工的な鍵はデータの完全性を維持するための絶対的な必要条件です。自然キーがある場合は、代わりにそれをキーフィールドとして使用できます。しかし、個人的には、自然キーが1つのフィールドでない限り、人工キーと自然キーに関する一意のインデックスをお勧めします。入れないと後で後悔するでしょう。
すべてのテーブルにPKを設定するのは良い習慣ですが、必須ではありません。たぶんあなたはあなたの必要性に応じてユニークなインデックス、そして/またはクラスタ化されたインデックス（これはPKかどうかではない）を必要とするでしょう。
Books Onlineの（SQL Server用）主キーとクラスタ化インデックスのセクションをご覧ください。
"PRIMARY KEY制約は、テーブル内の行を一意に識別する値を持つ列または列のセットを識別します。テーブル内の2つの行に同じ主キー値を指定することはできません。NULLを入力できません各テーブルには主キーが必要で、主キーの値として適している列または列の組み合わせは、候補キーと呼ばれます。 "
しかし、それからまたこれをチェックしてください： http://www.aisintl.com/case/primary_and_foreign_key.html
.NETでgridviewの特定の機能を使用するためには、gridviewがどの行を更新または削除する必要があるかを知るために主キーが必要であることを私は知っています。一般的な方法は、主キーまたは主キークラスタを持つことです。私は個人的に前者を好みます。
それを将来の証拠にするためには、本当にすべきです。あなたがそれを複製したいならば、あなたはそれを必要とするでしょう。もしあなたがそれを他のテーブルに参加させたいのなら、あなたの人生（そして来年それを維持しなければならない貧しい愚か者のそれ）はとても簡単になるでしょう。
最初は主キーがありますが、最初はまだそのための目的はありません。私は結局それを持っていないテーブルでPKを必要とする時が何度かありました、そしてそれは後でそれを入れるのはいつももっと面倒です。私はいつもそれを含むことにもっと多くの利点があると思います。
Hibernateを使用している場合は、主キーなしでエンティティを作成することはできません。普通のsql/ddlスクリプトを使って作成された既存のデータベースを使っていて、主キーが追加されていない場合、この問題は問題を引き起こす可能性があります。
私は、オフショア開発チームによって作成されたアプリケーションを保守する役割を担っています。元のデータベーススキーマには一部のテーブルにPRIMARY KEYSが含まれていなかったため、アプリケーションでさまざまな問題が発生しています。それで、あなたの貧しいデザインのために他の人々を苦しませないでください。テーブルに主キーを設定することは常に良い考えです。
一言で言えば、いいえ。ただし、特定のクライアントアクセスCRUD操作にはそれが必要であることに留意する必要があります。将来の校正のために、私は主キーを常に利用する傾向があります。
提案された答えに同意しません。簡単に言えば、NOです。
主キーの目的は、他のテーブルとの関係を形成するためにテーブル上の行を一意に識別することです。伝統的に、自動インクリメントされた整数値はこの目的のために使用されますが、これにはバリエーションがあります。
ただし、時系列データのロギングなど、そのようなキーの存在は単に必要ではなく、単にメモリを占有するだけの場合もあります。行を一意にすることは、単純に...必須ではありません。
小さな例：表A：LogData
Columns: DateAndTime, UserId, AttribA, AttribB, AttribC etc...
主キーは必要ありません。
表B：ユーザー
Columns: Id, FirstName, LastName etc.
LogDataテーブルの「外部キー」として使用するために必要な主キー（Id）。