4

以下をモデル化する最良の方法は何ですか...

と の 2 つのオブジェクトがAgencyありPublisher、どちらも と 1 対 n の関係にあるとしEmployeeます。これは真の 1 対 n の関係であり、それぞれが 1 つまたは 1 つEmployeeの に対してのみ機能します。さらに、1 対 n の関係を保持するスーパータイプ (例: ) を導入できないと仮定しましょう。AgencyPublisherEmployer

私の推奨する解決策は、またはEmployeeの主キーにリンクできる外部キーを含めることです (すべての主キーは、データベース全体で一意の 64 ビット ID です)。ただし、これがor関係であるかどうかを示さずに、双方向の関連付けをマッピングすることはできなくなりました。AgencyPublisherEmployeeAgencyPublisher

私のもう 1 つのオプションは、2 つのテーブル と を使用することですAgencyEmployee。PublisherEmployeeこれらは、従来の 1 対 n の双方向の関連付けとしてリンクできます。

この状況でのベストプラクティスは何だと思いますか?

更新: このような短い時間で素晴らしい応答をありがとう! 次の解決策についてどう思いますか:と などのとEmployeeの両方の外部キーAgencyPublisheragency_idpublisher_id

4

6 に答える 6

0

CanBerkGüderの+1。

技術的には、Employerスーパータイプを導入するということは、エージェンシーとパブリッシャーに共通のすべての属性を持つEmployer関係、EmployerキーとすべてのAgency固有の属性および外部キーとしてのEmployerキーとのAgencySpecific（呼び出し方法がわからない）関係を導入することを意味しますキー、次にエージェンシーをクエリまたはビューとして、エージェンシースペシフィックとエンプロイヤーを結合します。同様にパブリッシャーの場合も同様です。

エージェンシーとパブリッシャーのデータを毎回結合する必要のある2つのテーブルに分散させるのは少し面倒かもしれませんが、代わりに、エージェンシーを使用して1回はパブリッシャーを使用し、次にハンドクラフトを使用して、従業員に関連するクエリのほとんどを2回記述します。結果を組み合わせるための彼らの組合。（このような基本的なことを支援するクエリビルダーは見たことがありません。）「スーパータイプなし」のアプローチを使用したプロジェクトでそれを行う必要があり、二度とやりたくありません。

ところで、三項関係やn対nの関係でさえ、私に言わせれば良い設計手法ではありません。関数（つまり、1対nおよび1対1）のみを使用すると、たとえば、制約の定式化がはるかに簡単になります。

于 2009-03-11T17:17:37.783 に答える
0

明らかに雇用主の実体が好まれますが、そうでなければ...

AgencyEmployeeテーブルとPublisherEmployeeテーブルがあるということは、従業員が1つのカテゴリに属しているか別のカテゴリに属しているかを判断するのが難しいことを意味します。

したがって、代わりに、EmployerType列をEmployeesテーブルに追加します。後続のSQLクエリが少し複雑になりますが、指定した制約内で機能します。

興味深いことに、AgencyEmployeeテーブルとPublisherEmployeeテーブルを追加できるのに、Employerテーブルを追加できないのはなぜですか。ちょっと興味があるんだけど...

于 2009-03-11T17:04:17.300 に答える