データベース テーブルには常に主キーを設定する必要がありますか?
SOタグ付けを見てみましょう。どのリビジョンでもタグを確認できます。タグは、postID とリビジョン番号を持つ tag_rev テーブルにある可能性があります。そのためにPKが必要ですか?
また、rev テーブルにあり、現在は使用されていないため、複数の post_id タグ ID ペアの複数のエントリではなく、タグ ID のブロブにする必要がありますか?
データベース テーブルには常に主キーを設定する必要がありますか?
SOタグ付けを見てみましょう。どのリビジョンでもタグを確認できます。タグは、postID とリビジョン番号を持つ tag_rev テーブルにある可能性があります。そのためにPKが必要ですか?
また、rev テーブルにあり、現在は使用されていないため、複数の post_id タグ ID ペアの複数のエントリではなく、タグ ID のブロブにする必要がありますか?
各行を一意に識別できるように、テーブルには主キーが必要です。
技術的には、主キーなしでテーブルを作成することはできますが、適切なデータベース設計規則に違反することになります。
そのキーで個々のレコードにアクセス (または更新または削除) する可能性が高い重要なテーブルには、主キーを設定するように努める必要があります。主キーは複数の列で構成でき、正式には、利用可能な最短のスーパーキーになります。つまり、すべての行を一意に識別する、利用可能な列の最短グループです。
スタック オーバーフロー データベース スキーマがどのように見えるかはわかりません (ジェフのブログで読んだことのいくつかから、私はしたくありません) が、あなたが説明した状況では、プライマリが存在する可能性は十分にあります。投稿識別子、リビジョン番号、タグ値全体のキー。確かに、それは利用可能な最短の (そして唯一の) スーパーキーです。
2 番目のポイントに関しては、アーカイブ テーブルで値を集計することに賛成するのは合理的かもしれませんが、テーブル内の各行/列の交点には 1 つの値を含める必要があるという原則に反します。開発が少し簡単になるかもしれませんが、タグのように些細なことであっても、バージョン管理されたメタデータを使用して正規化されたテーブルを維持できない理由はありません。
整数の主キーが必要かどうかについては、この関連する質問を参照してください。回答の 1 つは、タグ付けを例として使用しています。
整数の主キーのないデータベース テーブルを使用する正当な理由はありますか
タグ付けとキーの詳細については、次の質問を参照してください。
ほとんどのテーブルには主キーが必要であることに同意する傾向があります。意味のないことは2回しか思い浮かびません。
基本的に、外部キー関係で参照する必要がある可能性のあるテーブルを作成している場合は、主キーが重要です。肯定できない場合は、PK を追加するだけです。:)
MySQL 5.5 リファレンス マニュアルのセクション13.1.17 から:
PRIMARY KEY がなく、アプリケーションがテーブルで PRIMARY KEY を要求した場合、MySQL は NULL カラムを持たない最初の UNIQUE インデックスを PRIMARY KEY として返します。
したがって、技術的には、答えはノーです。ただし、他の人が述べているように、ほとんどの場合、非常に便利です。
すべてのテーブルには、レコードを一意に識別する方法が必要であると固く信じています。テーブルの 99% では、これが主キーです。残りの部分については、一意のインデックスを使用できます(ここでは、1 つの列がタイプ テーブルを参照していると考えています)。レコードを一意に識別する方法がないテーブルを操作しなければならないときはいつでも、問題がありました。
また、代理キーを PK として使用している場合は、可能な限り、自然キーを構成するフィールドの組み合わせに個別の一意のインデックスを作成する必要があると思います。真の自然キーを持っていない場合が多すぎると思います (名前が一意ではないか、何かを一意にするものが複数の親子テーブルに分散している可能性があります) が、持っている場合は確認してください一意のインデックスを持つか、PK として作成されます。
PKがない場合、単一の行をどのように更新または削除しますか?それは不可能でしょう!正直なところ、たとえばアクティビティログを保存するために、PKなしのテーブルを数回使用しましたが、この場合でも、タイムスタンプを十分に細かく設定できなかったため、テーブルを使用することをお勧めします。一時テーブルは別の例です。しかし、関係理論によれば、PKは必須です。
鍵と関係があるのは良いことです。とても役に立ちます。ただし、アプリが関係を処理するのに十分な場合は、キーをスキップできます (ただし、キーを持っていることをお勧めします)
私は Subsonic を使用しているので、常にすべてのテーブルの主キーを作成しています。多くの DB 抽象化ライブラリは、機能するために主キーを必要とします。
注:それはあなたの質問の「大統一理論」のトーンには答えませんが、実際には、すべてのテーブルに主キーを作成する必要がある場合があると言っているだけです。
データベース自体にはキーがありませんが、それらを構成するテーブルにはキーがある場合があります。そういう意味だと思いますが、念のため…
とにかく、多数の行を持つテーブルには絶対に主キーが必要です。害はありませんが、数行しかないテーブルでは必ずしも必要ではありません。用途やテーブルのサイズによって異なります。純粋主義者は、すべてのテーブルに主キーを配置します。これは間違っていません。また、小さなテーブルで PK を省略することもありません。
この質問に関するブログ エントリへのリンクを追加するように編集しました。この質問では、データベース管理スタッフが特定のテーブルに主キーを含める必要があるとは考えていなかったケースについて説明します。これは私の主張を十分に示していると思います。