私は銀の弾丸を信じるつもりはありませんが、データベース テーブルの主キー列として、シーケンスまたは自動番号付け ID 列を使用するのが本当に好きです。それらは一意であり、適切にインデックス化されており、null 値について心配する必要はありません。
一方、テーブル内に同じ目的を果たすことができる他の一意の列がある場合、それらは冗長に見える場合があります。たとえば、9 桁の郵便番号を都市ゾーンにマップするテーブルを作成しているとします。郵便番号フィールドも同様に機能します (データ形式が保証され、値が重複しないことが前提です)。
要するに、私の経験は、私たちの誰にとってもそうであるように、限られています. 自動付番列をテーブルの主キーとして使用しないことを選択するようになった他の実例と、その理由は何ですか?
これは私にとって「視野を広げる」タイプのことであり、膨大な数のデータベースを扱ってきた人たちから少し学びたいと思っています。
IMHOは、最も単純なテーブルでさえ将来さらに重要になる可能性があるため、ID列を使用することが重要です。
使用しないのは、代わりにGUIDを使用した場合のみです。おそらく、切断されたクライアントでレコードが作成され、中央システムと同期する必要がある場合です。
私の経験則は次のとおりです。「通常の使用法でレコードを追加する場合は、自動インクリメントPKを使用します。静的テーブルの場合は、より「自然な」識別子を使用します。」
IOW：ユーザー、履歴レコード、資産。すべてが自動インクリメントPKを取得します。zip / city、type / description、マシンIDは、通常、「自然」キーを取得します。
複合キーの最も明白な選択肢として、リンク テーブルが思い浮かびます。
私はほとんど例外なく技術的な主キーの使用を固く信じているので、私の答えは...決してないはずです。
通常、頻繁なデータのダンプ/ロード/マージが必要で、外部キーの関係がある状況では、auto_increment列を避けます。自動インクリメントIDを使用する同じスキーマの2つのテーブルインスタンスからのデータをマージしようとすると、恐ろしい問題になります。
この種の使用法はほとんどの場合発生しませんが、私の仕事には多くのバッチ処理が含まれ、各バッチは後で分析/使用するためにマスターデータベースにマージされます。
実際に ID 列を使用すると考えられるのは、主キーを作成するために必要なフィールドの数が多い場合、または主キーであるフィールドが非常に大きい場合 (20 文字の文字列など) だけです。他のすべての場合、私はそれらを使用しないことを好みます。
ID に関して誰も持ち出さない問題は、データに何かが起こったときに何が起こるかということです。キーはレコードがいつ追加されたかのみに基づいているため、壊滅的なイベントの後にテーブルにデータを再ロードすることは実際の問題です。これで、dbms があなたを助け、誰かがテーブルを切り捨てたり、主キーの値を切り替えたりするのを防ぐはずです...はずです。何かが起こり、テーブルが壊れたり、データベースの更新で問題が発生したりします。ID プライマリ キーを使用すると、突然、どの ID 値がどの行に対応するかを把握しようとして混乱が生じます..データに関して ID 値は意味を持たないため、できません。 . ほんの一握りのエントリで、大丈夫かもしれませんが、しかし、おそらく数百万の値を持つ大きなテーブルを作成し始めると (これが発生したとき、私たちのテーブルは 1,100 万を少し超えていました)、急いで本当に問題が発生します。誰もが「それは最悪のシナリオだ、絶対に起こらないだろう」と言います。それはそれまでです。
自動番号フィールドを使用していない領域の1つは、スタースキーマの一部としてDateDimensionテーブルを定義する場合です。この例では、日付をyyyymmdd形式で表す整数を使用しました。これにより、中央のファクトテーブルとDateDimensionの間の高速結合が可能になりました（自動番号ID列も同様です）。でも ...
DateDimensionテーブルには、他の日付表現（smalldatetime列、dayOfWeek列など）が含まれていました。ユーザーがyyyymmdd形式の日付のみを必要とする場合は、中央のファクトテーブルの日付ディメンションキーにこの情報が既に格納されているため、結合は必要ありませんでした。
一般的に、私はビジネス情報を含むキーの大ファンではありません。通常、スキーマを設計するときに主キーについて行う仮定は、時間の経過とともに当てはまらず、行き詰まりがなくなります。この場合、私は日付がそうしないとかなり確信していました！
Iain Hoult、Javier、および TK によって表明された原則の 1 つの例外は、従業員番号または「バッジ番号」を人事テーブルの PK として使用することです。この場合、従業員に人事記録の PK を渡したという理由だけで、PK は「意味のあるキー」と呼ぶことができます。
-アル。