テーブルを設計する際、私は 1 つの列を一意にして主キーにする習慣を身に付けました。これは、要件に応じて 3 つの方法で実現されます。

1. 自動的に増分される ID 整数列。
2. 一意の識別子 (GUID)
3. 行識別子列として使用できる短い文字(x)または整数(またはその他の比較的小さな数値型)の列

番号 3 は、比較的小規模な検索に使用され、主に、一意の静的な長さの文字列コード、または年やその他の番号などの数値を持つテーブルを読み取ります。

ほとんどの場合、他のすべてのテーブルには、自動増分整数または一意の識別子の主キーのいずれかが含まれます。

質問 ：-）

私は最近、一貫した行識別子を持たず、主キーが現在さまざまな列にクラスター化されているデータベースの操作を始めました。いくつか例を挙げます。

• 日付時刻/文字
• 日付時刻/整数
• 日付時刻/varchar
• char/nvarchar/nvarchar

これには有効なケースがありますか? このようなケースでは、常に ID 列または一意の識別子列を定義しています。

さらに、主キーがまったくないテーブルも多数あります。 これには、どのような正当な理由がありますか?

テーブルがなぜそのように設計されたのかを理解しようとしていますが、私には非常に混乱しているように見えますが、おそらくそれには正当な理由があったのでしょう。

答えを解読するのに役立つ 3 番目の質問: 複合主キーを構成するために複数の列が使用される場合、代理キーや人工キーと比較して、この方法には特定の利点がありますか? 主にパフォーマンス、メンテナンス、管理などについて考えています。