2

簡単な古典的な例があります

Products -> ProductCategories <- Categories

一部のOR/M（Linq2SQLなど）は、PKなしの「Products」にナビゲーションプロパティ「ProductCategories」を生成したくない場合がありますが、これはリンクテーブルのみですか？このテーブルにPKが含まれている場合（わかりました）、すべてのCRUD操作を実行できます。それ以外の場合はtrueです（複雑なキーProductsId + CategoryIdを使用して各行を操作できます）

PS私はProductCategories.ProductsId+ProductCategories.CategoriesIdのような制約を作成するために使用されます

では、パフォーマンスの観点から、どちらのアプローチがより役立つでしょうか？

4

1 に答える 1

1

私はほぼ常に PK の使用をお勧めします。一つには、正規化のために必要です。もう 1 つの例として、クラスター化インデックス (技術的には PK と同じではありませんが、既定ではクラスター化インデックスは PK で定義されます) は一般的にパフォーマンスに役立ちますが、その程度は使用特性に大きく依存します。また、ご指摘のとおり、SQL データベースで動作する多くの ORM やその他のフレームワークは、構造上の目的で PK を想定しています。

状況によっては、リンク テーブルの両方の列に単純に PK を作成することが理にかなっていることがよくありますが、すべてのテーブルに整数の Id 列があることを期待する 1 つのフレームワークを使用したことがあります。

于 2012-05-16T20:35:49.623 に答える