0

次のデータベース設計があります。

ここに画像の説明を入力

Anには、いくつかの s を持つE-Reportものがあります。Aとそのs は、複数の で使用できます。QAPRequirementQAPRequirementE-Report

各Requirement電子レポートには、はい/いいえの確認があります。要件確認の値を保存するために追加しましEReportReqた (ユーザーがこれらの値を設定します)。

また、それぞれにRequirement複数の. との関係になります。ImageE-ReportEReportReqImgImageRequirement

このデータベース モデルの詳細が必要な場合は、お知らせください。

私の質問はEReportReqテーブルについてです。EReportReqId列が主キー ( )として必要なのか、主キーとしてeReportIdandを使用できるのかわかりませんrequirementId。

これらの 2 つの列を主キーとして使用する場合、eReportIdこれらrequirementId2 つをEReportReqImgテーブルに追加する必要があるため、このアプローチが私の方法よりも優れているかどうかはわかりません。

どう思いますか？

4

2 に答える 2

2

私の質問はEReportReqテーブルについてです。EReportReqId主キー（ ）として列が必要なのか、それとも主キーとして使用できるeReportIdのかわかりませんrequirementId。

あなたはそれらのどちらかを使うことができます-それらのどれも絶対に「より良い」ものではありません。最初のアプローチを使用する場合は、にUNIQUE制約も作成することに注意してください{eReportId, requirementId}。

最初のアプローチ（非識別関係と代理キーを使用）は、次のことにつながります。

  • EReportReqImg子テーブル（この場合は）の「リーナー」外部キー-すでに述べたように、
  • カスケードONUPDATEは子に伝播しません（したがって、更新すると、カスケード更新されるEReport.eReportIdだけEReportReq.eReportIdで、カスケード更新されませんEReportReqImg.eReportId）
  • ORMにとってより親しみやすいものになります。

一方、2番目のアプローチ（関係と自然キーを識別する）：

  • EReportReqImg JOIN EReportReqJOINの必要性が潜在的に少なくなります（たとえば、単に調べる必要はありませんrequirementId-直接にありますEReportReqImg.requirementId）、
  • クラスタ化されたテーブルに適しています（たとえばEReportReq、同じ行はeReportId物理的に「近く」に格納されるため、一部のクエリに大きなメリットがあります）
  • 代理キーの追加のインデックスを回避します。

子テーブルの数が少ないため、「ファット」FKはそれほど重要ではなく、IDを処理しているため、IDが変更される可能性は低く、更新時のカスケードが問題になる可能性はほとんどありません。ですから、私の本能は2番目のアプローチを採用することですが、他の考慮事項があり、決定を別の方向に導く可能性があります...

于 2012-06-27T16:08:03.860 に答える
0

この状態から始めましょう。

これら2つをEReportReqImgに追加する必要があります

一般に、PK として 2 FK を使用するのは、変更不可能なデータの通常の方法です。したがって、別のキーにドラッグするか、複合キーを使用するEReportReqような方法で変更することは想定されていません。それ以外の場合は、単一値の主キーを使用する方が堅牢で効率的です。これは、その間変更されないため、トリガーを書き込んだり、トリッキーなカスケードを使用して子テーブルを更新したりする必要がないためです。requirementIdeReportId

確認する他のオプションは、結果 SQL の単純さです。複雑よりも単純です。2 つのフィールドを使用した書き込みINNER JOINは複雑な構造であり、キーの 1 つを逃すバグの場所が潜在的に存在します。

于 2012-06-27T16:05:19.293 に答える