32

継承をサポートしていないリレーショナル データベースに継承のあるクラスを永続化する必要がある場合のヒント/テクニックは何ですか?

この古典的な例があるとします：

Person -> Employee -> Manager
                   -> Team lead
                   -> Developer
       -> Customer -> PrivilegedCustomer
                   -> EnterpriseCustomer

データベースを設計するために利用できる手法は何ですか? それぞれの長所と短所は？

psデータベースの継承に関するいくつかの質問を検索して見つけましたが、ほとんどはそれをネイティブにサポートするデータベースエンジンへの変更に関するものでした。しかし、SQL Server 2005 に行き詰まっているとしましょう...どのような選択肢がありますか?

4

3 に答える 3

28

3 つの一般的な戦略:

  1. 各クラスに定義されたプロパティを含む階層内の各クラスのテーブルと、最上位のスーパークラス テーブルに戻る外部キーを作成します。したがって、列を持つやvehicleのような他のテーブルを持つテーブルがあるかもしれません。ここでの欠点は、1 つのクラス タイプを取得するためだけに多くの結合を実行する必要がある場合があることです。carairplanevehicle_id

  2. すべてのプロパティを含む階層内のクラスごとにテーブルを作成します。シーケンスのようなものを使用していない限り、すべてのテーブルで共通の ID を維持するのは簡単ではないため、これは注意が必要です。スーパークラス タイプのクエリには、問題のすべてのテーブルに対するユニオンが必要です。

  3. クラス階層全体に対して 1 つのテーブルを作成します。これにより、結合と共用体が排除されますが、すべてのクラス プロパティのすべての列が 1 つのテーブルにある必要があります。一部の列は異なるタイプのレコードに適用されないため、おそらくほとんどの列を null 可能のままにしておく必要があります。たとえば、vehicleテーブルwingspanには、型に対応するという列が含まれている場合がありますAirplane。この列を NOT NULL にCarすると、テーブルに挿入された のインスタンスには値が必要になりますが、wingspanの値のNULL方が理にかなっています。列をヌル可能のままにしておくと、チェック制約でこれを回避できるかもしれませんが、見苦しくなる可能性があります。(単一テーブルの継承)

于 2008-12-22T16:30:31.193 に答える
7

特定の状況ではデータベースの継承に注意してください。監査戦略のためにアプリケーションに実装しましたが、パフォーマンスのボトルネック/悪夢に陥りました。

問題は、使用したベース テーブルが挿入のみで急速に変化したため、いたるところでデッドロックが発生したことでした。現在、これらを独自のテーブルに分割することを計画しています。パフォーマンスの悪夢に対して、15 の異なるテーブルに同じ列を配置するという頭痛の種は、それだけの価値があるからです。これは、エンティティ フレームワークが必ずしも継承を効率的に処理するとは限らないという事実によっても悪化しました (これは Microsoft による既知の問題です)。

とにかく、この問題を解決してきたので、いくつかの知識を共有したいと思いました.

于 2011-10-18T23:30:08.680 に答える
5

次のリンクの第 8 章継承マッピングでも、これについて説明されています。http://nhibernate.info/doc/nh/en/index.html#inheritance

それはNHibernateのドキュメントです。

于 2008-12-22T17:26:44.527 に答える