1

ユーザーがデータを追加する E-Report と呼ばれるフォームを表す必要があります。

すべての E-Reportには がありQAP、すべてQAPには 2 つ以上の がありDefectsます。

これらの欠陥は、次の表に示されています。

ここに画像の説明を入力

最初は、このテーブルには 2 つの欠陥があり、ユーザーは QAP からさらに欠陥を追加したり、必要に応じて新しい欠陥を挿入したりできます。

ユーザーは、、、および列をチェックするかどうかをCRS選択し、これらCRFのデータをテーブルに保存します。MAMIEReportDefect

ところで、QAPデータDefectはWeb サービスになるので、Android デバイスにダウンロードする必要があります。これら 2 つのテーブルを変更してデータを追加することはできません。

私がこの Visio を設計したことを表すには:

ここに画像の説明を入力

Defectテーブルにデータを追加できないため、 、、およびユーザー データを格納し、ユーザーが作成した新しい欠陥を格納するEReportDefectテーブルを作成しました。CRSCRFMAMI

Defectユーザーによって追加された新しいものを表すためにEReportDefect.defectId、NULL として設定し、EReportDefect.description新しい欠陥の説明を保存します。

これらの新しい欠陥には値がなく、値がオンにEReportDefect.defectIdなりますEReportDefect.description。

これは正しいです？NULL 値を持つ外部キー列を使用できますか? より良いアプローチを知っていますか？

4

1 に答える 1

3

Null 許容の外部キーは完全に受け入れられます。

次のケースを考えてみましょう。ユーザーが応答するように設計されたメッセージ テーブルです。

CREATE TABLE Messages 
(
  MessageId int,
  MessageText varchar(256),
  AnsweredByUserId int
)

これで、最初の未回答メッセージが最初に作成されるとき、AnsweredByUserId は NULL になります。それはまったく問題ありません。メッセージはまだ回答されていないため、そこに値が見つかるとは期待できません。

誰かがメッセージに応答した場合、そのユーザーの UserId を AnsweredByUserId に入れ、それが発生したときに参照制約を適用します (たとえば、挿入した UserId が実際に Users テーブルに存在することを確認したい)。

結論として、適切な状況で NULLABLE 外部キーを持つことは問題ありません。

于 2012-10-02T09:25:28.097 に答える