データ構造の質問

Question

このシナリオを処理する最良の方法は何ですか？私は、顧客のモデル（表）は、私が展望モデル（表） 顧客でない店舗訪問者のための連絡先情報が含まれています、私は機会のモデル（表）を持っているお客様 のための連絡先情報が含まれてい

のいずれかの場合、顧客またはプロスペクトが店を訪問します。

私の見解では、新しいoppportunityを生成したいと考えています。案件には、1つの顧客関連または1つの見込み顧客関連のみが含まれますが、両方は含まれません。

私の機会モデルでは、現在、顧客と見込客の両方がnullable foreign IDとナビゲーションプロパティを持っています。私はまた、機会モデルの顧客と見通しのためにICollection <を持っています。

これは、条件付き関連付けを処理する正しい方法ですか？

ビューになると、私は顧客や見込み客の関係をどのようにして作るのですか？

Answer 1

は、私はコンピュータサイエンスの学生ですが、これはDBの関係に関する私の理解です：

あなたは「人」の2種類があるので - 顧客 - と展望を - あなたが潜在的に「人」と呼ばれるテーブルを持つことができます。 Personテーブルには、両方のエンティティ間の共通データ（FirstName、LastName、Address1、Address2、City、State、Zipなど）が格納されます。

PersonがProspectであることを示すには、PersonsをPersonテーブルにリンクするProspectテーブルが必要です。見込み客に関するより詳細な属性をこの表に格納することができます。

PersonテーブルにリンクするPersonId列とCustomerエンティティの特定の属性を持つCustomerテーブルがあります。

ここでは、他のエンティティを派生させることができるデータベースがあります。たとえば、Employeeエンティティ>基本エンティティが始まります。また、Employeeテーブルはそのテーブルにリンクし、従業員固有のデータ用の他のカスタム列も持ちます。

それは意味がありますか？

また、私はこれについてすべて間違っています:)。私がまだ学生なので間違っていれば私を修正してください。

"オポチュニティ"レコード（Customer OR Prospect）に2つのフィールドがあり、そのうちの1つがnullである必要があるため、あなたは立ち往生していると思います。私が提案したモデルでは、あなたの機会はPersonにリンクし、従業員の機会（実際には悪い考えではないかもしれない）を制限するカスタムビジネスルールを定義することができます。

あなたの機会モデルの参照されたPersonについては、ICollectionではありません（特に機会には1人のみがいると言われています）。

private virtual Person Person { get; set; } 

EDIT：あなたは、データベース全体を再構築したくない場合は、あなただけの、これが（顧客、または見込みである機会の種類を尋ねるドロップダウンを持っている可能性があり、それは単にのような単一のクラスになります）。選択に基づいて、あなたの[オポチュニティ]テーブルに外部キーを追加して[顧客またはプロスペクト]にリンクします。