3

販売注文ヘッダー/詳細シナリオでは、詳細テーブルに任意の主キー (ID/GUID) を設定する必要がありますか?それとも、SalesOrderHeaderID 列と ProductID 列で構成する必要がありますか?

これは、2 行または 3 行の詳細テーブルで複合一意キーを作成できるマスター/詳細シナリオの一般的な質問です。(上記の例では、注文に重複した製品を含めることはできないと想定しています)。

4

5 に答える 5

1

自然な複合キーを選択し、後でデザインを変更して Order Details が別のテーブル (たとえば、出荷) の主キーになるようにした場合は、その複合キーを新しいテーブルに伝播する必要があります。その理由だけでも、任意の ID を主キーとして選択します。

また、これにより、注文に重複した製品が含まれる可能性がある将来の状況が可能になります

（この問いに対する答えは、もちろん正解のないエキュメニカルな問題です）

于 2012-10-08T10:56:48.330 に答える
0

ID/GUID の任意の主キーではなく、自然な主キーを選択します。自然キーを使用してエントリを一意にすることができる場合は、そのルートに進みます。

したがって、基本的なテーブル構造は次のようになります。

create table order
(
  order_id int -- PK
  order_date datetime,
  orderedby varchar(50)
);

create table products
(
  productid int, -- PK
  name varchar(50)
;

create table orderdetails
(
  order_id int,  -- PK/FK
  productId int  -- PK/FK
);
于 2012-10-08T10:52:53.460 に答える
0

テーブルにidentity列と複合キーを配置します。

設計は次のようになります。

  • SalesOrderDetailId (int、ID)
  • SalesOrderHeaderID (int、外部キー)
  • ProductID (int、外部キー)
  • その他のフィールドは必須です。

複合キーは引き続き両方のテーブルから使用されますが、複合テーブルから選択するときに、複合テーブルが独自の ID を持っていると一貫性があり便利です (個人的には、これにより混乱が少なくなります)。

于 2012-10-08T10:53:10.080 に答える
0

...SalesOrderHeaderID 列と ProductID 列で構成する必要がありますか?

問題の完全な説明を提供した場合は、はい。

ただし、言及していない他の基準がある可能性があり、追加の「代理」キーを優先してバランスを歪める可能性があります。

于 2012-10-08T16:32:47.663 に答える
0

上記のシナリオでは、詳細テーブルには、SalesOrderHeaderID 列と ProductID 列で構成される主キーが必要です。とにかく、SalesOrderHeaderID を詳細テーブルに格納してインデックスを作成する必要があるため、それを主キーの一部として使用しないでください。

実際には、SalesOrderHeaderID と注文明細番号の組み合わせを主キーとして使用するのが通常です。これは、同じ注文の同じ製品に対して複数の注文明細を記録できるようにするビジネス上の理由がしばしばあるためです。

于 2012-10-08T10:54:51.353 に答える