2

次のビジネス ケースのニーズがあります。

  1. 私はプロジェクトのデータベースを持っています。
  2. 各プロジェクトには、さまざまな役割 (プロジェクト所有者、サポートなど) で関連付けられた複数の人がいます。
  3. プロジェクトでは、1 人の人物が複数の役割を担う場合があります。
  4. プロジェクトに関する個人の連絡先の詳細は、プロジェクトの作成時に取得され、その個人の連絡先の詳細が更新されたときに、そのプロジェクトについて更新する必要はありません。

次のデータベース構造が提案されています。

ここに画像の説明を入力

ContactDetails は今のところ 1 対 1 として計画されていますが、1 つのプロジェクトの複数の人物/役割のマッピングが 1 つの ContactDetail を共有する可能性がある場合に備えて分離されています。

私の質問: 通常、私は自分のプロジェクトに関連する人々のリストをさまざまな役割でロードします。私がレイアウトした構造に基づいて、私のエンティティはここでどのように見えるべきですか: ProjectPerson は単なる相互参照ではなくエンティティになりましたか?

[アップデート]

他の人に役立つ場合に備えて、以下の回答に基づいて私の新しいデータ構造を含めます。アドバイス通り。 ここに画像の説明を入力

4

1 に答える 1

1

連絡先の詳細をProjectPeopleに移動し、ProjectPeopleと1対多の関係を持つ別のテーブルに役割を引き出します。

あなたの質問に答えるために、はいProjectPersonはあなたのドメインモデルのエンティティになりました。実際、単純な多対多のマッピングテーブル以上のものになるとすぐに1つになったと思います。

私たちも同様の構造を持っており、いくつかの課題があります。ProjectにはProjectPersonのコレクションがあり、Personには読み取り専用のProjectのコレクションがあるようにモデル化しています。

于 2012-12-17T19:28:11.193 に答える