テーブルの主キーは十分条件であって必要条件ではないんですが。
アクセスのMDBでは主キーが必須である影響で,アクセスシステムをスケールアップする案件の時、
主キーは必須だと信じているのを見かけます。DataTable/DataSourceの UPDATE文を実行する際にも主キーが必須なため、なおさら主キーにこだわるようですね。
少量データの際はキー設定しないほうが早かったり,効率がよくなったりします。
一方で,データの特性を無視し,無理からユニークキーを設定するのも見かけます。
例) 商品の受注データの明細の追跡管理テーブル (受注番号は永久連番とします)
受注明細ごとの商品の追跡データだから, キーワードは, 商品コード,受注番号,個数 となります。
商品ごとの管理という視点から 第一キーが商品コードで第二キーが受注番号の 商品コード+受注番号 を主キーに設定しています
違和感一杯なのです。
この追跡管理テーブルだと, 受注テーブルと対になるので,別テーブルにする意味がない。
受注番号自体がユニークキーで,それを第二キーに使うのは???
256歩譲って,追跡管理テーブルを作成するとして、商品コード,受注NOの二つの索引はあったほうがベターですが、主キーはどうするか、
サロゲート項目を追加し,永久連番項目を設置し,それを主キーにすることを私はしています。