不要な場合でも、すべてのテーブルにIDを追加しますか？

現在、このIDの使用状況（たとえば、MxNテーブル）が表示されない場合でも、データベースのすべてのテーブルにデフォルトでIDフィールドを追加するのは、この設計の良し悪しですか？

多くの場合、すべてのテーブルに人為的なIDがあると非常に便利です。いくつかのケースでは、それはa **の単なる苦痛です。

一般的に、私は取り組んでいるすべてのプロジェクトでそれを行います。

利点：

• IDtype と呼ばれるキーフィールドですべてのテーブルにアクセスできる場合は、一般にアクセスコードを記述または生成する方が簡単Integerです。

• 時々、自然キーは揮発性です。たとえば、すでに非常に複雑な倉庫管理システムでは、製品コードが変更されるというタスクに直面していました。たとえば、製品001234は将来的に002345として知られるようになります。残念ながら、そのシステムは人工的なIDを使用しませんでしたが、製品コードを主キーとして使用しました。当然、製品コードは他の何十ものテーブルの外部キーでもありました。そのため、番号の付け替えは非常に困難で費用がかかり、勤務時間中に行うことはできませんでした。ソフトウェアの次のバージョンは人工的なIDを使用したため、製品テーブルに対する単純なUPDATEでした。

• 場合によっては、本来あるべきキーであっても、自然キーは一意ではありません。私の国では、いくつかの理由により、いくつかのSSNが2回発行されています。

• 隠されたキーは、データ構造が複雑な場合に扱いにくくなります。4つの部分からなるキーが付いたサブサブサブテーブルを使用すると、作業がかなり面倒になります。

短所：

• その性質上、これらのIDはシステムの外部では意味がないため、これらのIDを自然なキーに変換するには多くのルックアップが必要です。

• 上記のサブサブサブテーブルからトップキーを取得するには、階層全体で大きな結合が必要です。

• 入力データを既存のレコードとマージすることは、さらに多くのルックアップが必要になるため、より困難になります。

合成キーと自然キー、および単一キーと複合キーはどちらも、双方に良い面と悪い面がある、活発に議論されているトピックです。それらは、独自の行の議論におけるタブ対スペースおよび中括弧のようなものです。

最も重要なことは、データベース全体で一貫性を保つために、どちらか一方を選んでそれを守ることです。一般的に、すべてのテーブルに適切な自然キーを設定するのは難しく、すべてのテーブルに合成キーがある場合は、一貫性を保つのがはるかに簡単なため、合成キーが使用されます。

すべてのテーブルには、PK、一意の識別子、またはIDが必要です。MxNの場合、PK（複合1）があります。したがって、別のものを用意する必要はありません。

関連項目： 多対多テーブルの1つまたは2つの主キー？

関連トピックに関する私の個人的な好み：PKは、PKであること以外に他の用途があってはなりません。したがって、データが「自然に一意」のIEであるとしても、PKのデータは使用しません。SSN、日付、郵便番号など。

設計の観点からは、自然な複合主キーを使い、合成キーを発明しないでください。存在する必要がないものは、スキーマを理解するのをより複雑にするだけです。

多くのデータベースのパフォーマンスの観点から、他のインデックス付きの列よりも整数の主キーでテーブルにアクセスする方が高速です。これらのデータベースは、このような合成キーを持たないテーブル（通常は「ROWID」または「OID」などと呼ばれる）にも暗黙的に追加するため、明示的に追加してもコストはまったくかかりません。

MxN（リレーション）テーブルの場合、主キーでアクセスしても意味がありません。どちらかのコンポーネントによってそれらにアクセスし、関連するエンティティのセットを反対側から取得します。したがって、これらのテーブルでは、合成主キーを追加しても意味がありません。

適切に構成された、または整数以外の主キーを持つ他のテーブルについては、最初は合成キーを追加しませんが、パフォーマンスが重要なテーブルでアクセスされるテーブルのパフォーマンスチューニング中に追加することを検討します。