私はデータベースを持っています。私にはメーカーがあり、ディストリビューターにはほとんど例外なくほぼ同じ情報を含む別々のテーブルがあります。両方のグループには、接続が必要な連絡先が1つだけあります。連絡先情報を保持する連絡先テーブルを作成しました。1対多のデータベース関係の共有エンティティ
私は2番目のコンタクトテーブルが必要ですか？私はこれをDRYとして可能な限り作ろうとしています。どのように見えるだろうか？事前にありがとう
多分party-role patternの場合ですか？ ManufacturerおよびDistributorは、締約国が果たす役割です。連絡先は、参加者が果たす役割ではなく、締約国に適用されます。だから、必要があると思います：
PartyContactMethod（または類似）という名前のテーブルというテーブルを2つのContactテーブル。ロールの側面をモデル化する方法は、より広い要件に依存します。標準的なモデルは持っているでしょう：
Roleという単一のスーパータイプM：役割（注：これにより、これにより、製造者とディストリビューターの両方の役割を担うことができます（関連性がある場合もあります）。
をあたり全体階層の（：
リレーショナルテーブルのサブタイプの階層を実現するための3 '標準' のパターンが存在します1）は、ロール固有の関係がない場合に適用されます。 （しかし、そうは思わない;おそらくメーカーには適用されないディストリビューターに関連する情報があり、逆も同様である）。
（2）は、パーティからの複数の関係（つまり、1つの役割サブタイプ）を意味する。
（3）は上記の両方を回避しますが、Partyからその役割への移動に余分な参加を意味します。
私が言うように、選択肢は幅広い要件に依存します。
hth。