問題タブ [class-table-inheritance]

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

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

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

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

さまざまな車両の衝突試験データを格納するデータベースをセットアップしているとします。スピードボート、乗用車、ゴーカートの衝突試験のデータを保存したいと考えています。

SpeedboatTests、CarTests、および GokartTests の 3 つの個別のテーブルを作成できます。ただし、多くの列は各テーブルで同じになります (たとえば、テストを実行した人の従業員 ID、衝突の方向 (正面、側面、背面) など)。ただし、多数の列が異なるため、すべてのテスト データを 1 つのテーブルにまとめることは望ましくありません。スピードボートでは常に null になる列がかなり多く、常に null になる列がかなりあるからです。車の場合は null になり、ゴーカートの場合は常に null になるものがかなりあります。

テストに直接関係のない情報 (テスト対象の設計者の従業員 ID など) も保存したいとします。これらの列は、特に同じ車両のすべてのテストで繰り返されるため、「テスト」テーブルに配置するのは適切ではないようです。

関連する質問を確認できるように、考えられるテーブルの配置を 1 つ示しましょう。

この構造の良い点/悪い点、およびこのようなものを実装するための好ましい方法は何ですか?

Vehicles テーブルに含めたいすべての車両に適用される情報もある場合はどうでしょうか。CarTests テーブルは次のようになりますか...

これは王室の混乱になりつつあるようです。このようなものをどのように設定する必要がありますか?

com.something.SuperClass:

com.something.SubClass:

私にこの例外を与えます:

ID を生成するための最善かつ最も便利な方法は何ですか? 継承戦略を変更したくありません。

一般的なスーパークラスとして機能する電子デバイスのテーブルがあり、電話、ラップトップ、カメラなどのサブクラス テーブルを分離して、スーパークラスを拡張し、デバイスに関する特定の情報を提供します (スーパークラス テーブルの外部キー deviceID を使用)。つまり、Class Table Inheritanceです。私の質問は、スーパークラスに「deviceType」列が必要ですか? 特定のデバイス ID がどのサブクラス テーブルに表示されるかを確認することでデバイス タイプを検出できるため、冗長になりますが、非常に単純なものを検出するには、不要な量の結合が必要になるようです。

一般的に、ランダムな汎用デバイスを見て、それが何のタイプなのか疑問に思う人はおそらく珍しいでしょうが、その人が簡単にそれを見つけるのが難しい設計のままにしておくのも奇妙に思えます。

別の問題は制約です...デバイスのサブタイプが1回だけになるように制約するにはどうすればよいですか? 同様に、Camera テーブルに既に存在する行と同じ deviceID を持つ行が Laptop テーブルに追加されるのを止めるにはどうすればよいでしょうか? 繰り返しますが、これが優れた UI で可能になる可能性はほとんどありませんが、データベースの制約は常に望ましいものです。

ありがとう！

PS deviceType 列を使用する場合、データの整合性を高めるために、フリー テキスト フィールドではなく、サポートするすべてのデバイス タイプの列挙テーブルにリンクされます。

明確化のために追加

最初はスーパークラス テーブルです。

汎用デバイス

次に、2 つのサブクラスの例を示します。

ラップトップ

カメラ

GenericDevice テーブルから移行された "deviceID" のキーに注意してください。これにより、実際のデバイスのタイプに応じて、ジェネリック テーブルから任意のサブクラス テーブルへの 1 対 1 の関係が可能になります。したがって、これらの表を結合すると、HP デバイスは 17 インチ画面のラップトップであり、Canon デバイスと Ikon デバイスは両方とも、それぞれ 6.5 メガピクセルと 8 メガピクセルのカメラであることがわかります。

問題は、そもそもデバイスの種類がわからない場合に、どのようにしてデバイスの種類を特定するかということです。GenericDevice テーブルの行しかありません。例として最初の行を見てみましょう。デバイスが HP 製で、2009 年 5 月 6 日に出荷されたことはわかっていますが、最初はデバイスの種類がわかりません。しかし、deviceID = 1 の行が見つかるまで子テーブルを検索することで、それを見つけることができます。ラップトップ テーブルにはそのような行が含まれているため、HP デバイスは実際にはそのラップトップである必要があります。しかし、単純にデバイス タイプを検出するのは不必要な問題のように思えます (特に、deviceID が一致する場所を確認するために検索する必要がある 20 以上のサブクラスがある場合)。代わりに、これを行うことができます：

汎用デバイス

これで、HP デバイスのタイプをすぐに確認できます。しかし、今では重複データがあります (暗黙的に)。理由を確認するには、ユーザーがこの変更を行ったかどうかを検討してください。

汎用デバイス

(最初の行の deviceType は camera に切り替えられました)
これで、矛盾する情報が得られました。この上の表では、HP デバイスはカメラであると示されていますが、ラップトップ テーブルにはデバイスの行があります。つまり、事実上、HP デバイスのタイプを 2 回保存しています。1 回は GenericDevice テーブルの deviceType フィールドを使用し、1 回は単純に、Laptop テーブルに deviceID = 1 の行があるという事実によって。

My question is regarding Inheritance modeling in Relational Database Systems. I have canonical data model and in that I have some fields related to pricing of product inheriting certain attributes from product table and I want to model this inheritance in MySQL relational database and so,

"How can we do Inheritance Modeling in Relational Databases ?"

Thanks.

Castle Activerecord (NHibernate の上) では、クラス テーブルの継承をグローバルに使用し、継承ツリーの一部で単一のテーブルの継承を使用することは可能ですか? 私は次のようなことをしたいと思います

すべての共通の「もの」(名前、説明など) が「モデル」テーブルにあるように、「コンテナ」テーブルで STI を使用できます。それとも、これは時間の無駄であり、すべてのために STI に行く必要がありますか?

前もって感謝します、ジム

動物というクラスがある場合、犬と魚がサブクラスです。動物には「色」と呼ばれる属性があります。犬には「尾の長さ」という属性があり、魚にはこの属性がありません。魚には「体重」と呼ばれる属性がありますが、犬にはこの属性がありません。

そこで、この情報を保存するデータベースを設計したいと思います。私は何をすべきか？ここにいくつかのアイデアがあります：

アイデア1：動物のテーブルを作成し、テーブルにはタイプがあります。犬の場合、犬のテーブルから結果を取得するだけで、どのような動物を見つけることができます。

動物：色：文字列タイプ：int

タイプ：犬：0魚：1

犬：TailLength：int

魚：体重：int

アイデア2：犬のテーブルと魚のテーブルのみをデータベースに保存し、動物のテーブルを削除します。

犬：色：文字列TailLength：int

魚：色：文字列重量：int

PHP 用の Doctrine ORM (v1.2) を試しています。クラス「酒」を定義し、2 つの子クラス「ジン」と「ウイスキー」を定義しました。私は具体的な継承 (ほとんどの文献ではクラス テーブルの継承) を使用して、クラスを 3 つの個別のデータベース テーブルにマップしています。

私は次のことを実行しようとしています:

当初、私は $liquors が、ウィスキーであろうとジンであろうと、すべての酒を含む Doctrine_Collection であることを期待していました。しかし、コードを実行すると、whisky および gin データベース テーブルに複数の行があるにもかかわらず、空のコレクションが得られます。生成された SQL に基づいて、理由がわかりました。ORM は、実際のデータが格納されているウイスキー/ジン テーブルではなく、「酒」テーブルをクエリしています。

継承タイプを列集計 (単純なテーブル継承) に切り替えると、コードが完全に機能することに注意してください。

すべての酒類を含む Doctrine_Collection を取得する最良の方法は何ですか?

アップデート

さらに調査した結果、Doctrine がUNION舞台裏で SQL 操作を実行して、"whisky" テーブルと "gin" テーブルからの結果セットを結合することを期待しているようです。

これは、ポリモーフィック クエリと呼ばれます。

このチケットによると、この機能は Doctrine 1.x では利用できません。これは 2.0 のリリースを予定しています。( CTIの Doctrine 2.0 ドキュメントも参照してください)。

この情報に照らして、この欠陥を回避するための最もクリーンで効率的な方法は何でしょうか? 単一テーブルの継承に切り替えますか? 2 つの DQL クエリを実行し、結果の Doctrine_Collections を手動でマージしますか?

私は現在、Rails 3 アプリケーションに取り組んでいます。このアプリケーションは、いくつかのモデルで Class Table Inheritance を使用する必要があるようです。

何が起こっているかの簡単な例はこれです。

アプリケーション内のすべてのタイプの人々に共通で、認証に使用される、名前、電子メール、パスワードなどの一般的な属性を持つ Person というクラスがあります。

Person (または 2 種類の人) には、Driver と Passenger の 2 つのサブクラスがあります。これらのサブクラスはどちらも Person の一般的な属性を共有していますが、それ自体に固有の特定の追加属性を持っています。(たとえば、ドライバーは多くの車両とライセンスを持つことができますが、乗客はそうではありません)

この種の状況で CTI を実装するにはどうすればよいですか? ここで提供される例を見てきました：

http://rhnh.net/2010/08/15/class-table-inheritance-and-eager-loading

しかし、Driver オブジェクトまたは Passenger オブジェクトから Person の共通属性にアクセスする方法については推測していないため、少し混乱しています。

特に、私が知りたいのは次のことです。

Driver の属性を更新する場合、親 people テーブルの関連する属性に簡単にアクセスして更新するにはどうすればよいですか? after_save コールバックにフックして、どの属性の更新がどこに行くのかを分離する必要がありますか? または、これにアプローチするより良い方法はありますか？

I'm thinking about how to represent a complex structure in a SQL Server database.

Consider an application that needs to store details of a family of objects, which share some attributes, but have many others not common. For example, a commercial insurance package may include liability, motor, property and indemnity cover within the same policy record.

It is trivial to implement this in C#, etc, as you can create a Policy with a collection of Sections, where Section is inherited as required for the various types of cover. However, relational databases don't seem to allow this easily.

I can see that there are two main choices:

1. Create a Policy table, then a Sections table, with all the fields required, for all possible variations, most of which would be null.

2. Create a Policy table and numerous Section tables, one for each kind of cover.

Both of these alternatives seem unsatisfactory, especially as it is necessary to write queries across all Sections, which would involve numerous joins, or numerous null-checks.

What is the best practice for this scenario?