主キーが必要ない場合、データベースに追加するべきではありませんか?
12 に答える
主キーが必要です。あなたはまだそれを知らないだけです。
主キーは、テーブル内の行を一意に識別します。
インデックス化および/またはクラスター化されているという事実は、物理的な実装の問題であり、論理設計とは無関係です。
テーブルを意味のあるものにするために必要です。
主キーが必要ない場合は、使用しないでください。私は通常、主キーが必要なので、通常は主キーを使用します。関連するテーブルがある場合は、主キーと外部キーが必要になるでしょう。
いいえ、「table_x に主キーがなければ、このデータベースは非常にうまく機能するだろう」という例が見つからない限り、できません。
パフォーマンス、データの整合性、および正規化が必要ない場合は、主キーを使用しないという主張をすることができます。セキュリティとバックアップ/復元機能は必要ないかもしれませんが、最終的には大きなズボンをはいて、データベース実装の現実の世界に参加します。
はい。ただし、事故に遭う予定がなければシートベルトを着用しなくてもよいという意味でのみです。つまり、必要なときに大きな利益を得るために支払うのはわずかな代償であり、必要がないと思っていても、将来的には必要になる可能性があります. 違いは、自動車事故に遭うよりも主キーが必要になる可能性の方がはるかに高いということです。
また、一部のデータベース システムは主キーを作成しない場合に作成することも知っておく必要があります。そのため、エンジンで何が起こっているかという点ではあまり節約にはなりません。
はい、テーブルには常に主キーが必要です...テーブル内のレコードを一意に識別する必要がない場合を除きます。(私は絶対的な発言をするのが好きで、すぐにそれらに反論します)
テーブル内のレコードを一意に識別する必要がないのはどのような場合ですか? ほとんどは決してない。監査ログテーブルなどについては、以前にこれを行ったことがあります。更新も削除もされず、いかなる制約も受けないデータ。基本的に構造化されたロギング。
それは、あなたがそれを必要としないことをどれだけ確信できるかに大きく依存します. 少しでも疑問がある場合は、1 つ追加してください。後で感謝します。保存するデータが、ある時点で DB 内の他のデータに関連する可能性があるかどうかを示す指標。
私が考えることができる 1 つの使用例は、(後で適切に処理するために) エントリを次々にダンプする、ロギングのようなテーブルです。関連するメッセージ (日付など) を除外するのに十分なデータを格納している場合は、おそらく主キーは必要ありません。もちろん、これに RDBMS を使用するかどうかは疑問です。
良い...
リレーショナル DB の各テーブルには主キーが必要です。すでに述べたように、主キーはレコードを一意に識別するデータです...
2 つの異なるテーブルを結合する NM テーブルがある場合、「ID」フィールドがなくても済むかもしれませんが、結合する両方の列の値によってレコードを一意に識別できます。(複合主キー)
主キーのないテーブルを持つことは第一正規形に反し、リレーショナル DB では関係ありません
主キーは常にクエリのパフォーマンスに役立ちます。したがって、「キー」を「外部キー」に使用してクエリを実行する必要がある場合、またはルックアップとして使用する必要がある場合は、はい、外部キーを作成してください。
IDだけであっても、常に主キーが必要です。代わりに NoSQL を求めているのではないでしょうか?
主キーは、主に参照整合性を支援するために正式に定義されますが、テーブルが非常に小さい場合、または一意のデータが含まれる可能性が低い場合、不要なオーバーヘッドになります。テーブルにインデックスを定義すると、通常、主キーを正式に宣言せずに主キーを暗示するために使用できます。ただし、主キーを定義することは、開発者やスキーマ生成ツール、または SQL 開発ツールにとって役立つ可能性があることを考慮する必要があります。メタ データがあると理解が容易になり、モデル内の主キー/外部キーの関係を正しく定義するためにこれに依存するツールもあります。
知らない。単一の行と単一の列があるいくつかのテーブルを使用しました。常に 1 つの行と 1 つの列のみになります。外部キー関係はありません。
なぜ私はそれに主キーを置くのですか?