問題タブ [table-per-class]

流暢な nhibernate を使用して、次のようなマッピングを作成しようとしています。

これを行う方法についての考えは？

NHibernate を使用して、さまざまなタイプのオブジェクトの大きなツリーをロードしています。マッピングは、table-per-subclass 戦略を使用して実装されます。少数のフィールド (NodeId、ParentId、NodeType) と、Node から継承して独自のフィールドを追加するいくつかのサブクラスのみを持つ基本クラス「Node」を定義しました。

このアプローチの実装は簡単で、パフォーマンスについて文句を言うことはできません。異なるタイプの 10,000 個のオブジェクトの大きなツリーが、1 回のラウンドトリップを使用して数百ミリ秒以内に私の古いマシンに取り込まれます。ただし、気になる点が 1 つあります。このような戦略では、ノード テーブルが、定義されたサブクラスに対応する他のすべてのテーブルと外部結合される複雑なクエリが生成されます。異なるサブクラスの数が少ない場合はこれで問題ありませんが、数が増えると OUTER JOIN の複雑さも増します。

クラスごとにテーブルを定義することは洗練されたオプションではないようで、基本クラスからデータを選択するときに動作が遅くなります (UNION のため)。他のオプションでは、データベース サーバーへの往復回数が増えるようです。

では、さまざまな種類のエンティティで構成される大規模なツリーを作成する場合のベスト プラクティスは何だと思いますか? サブクラスごとのテーブルよりも優れたものはありますか?

HibernateJPAを使用しています。

私がこれらのクラスを持っているとしましょう：

具体的なクラスに独立したIDを持たせる方法はありますか？

InheritanceType.TABLE_PER_CLASSを使用しています。

いくつかの種類のドキュメントをスキャンするドキュメントスキャンシステムがあります。最初は、ドキュメントはスキャンされたときに情報を持っていません。その後、ドキュメントは分類され、後の2番目のステップで追加情報が入力されます。したがって、Documentという基本クラスと、以下のようにそれぞれのメタデータを持つ各タイプのサブクラスがあります。NHibernateでサブクラスごとのテーブル（結合されたサブクラス）マッピングとしてセットアップしました。

私ができる必要があるのは、最初にDocumentクラスを作成し、それを保存することです。次に、後の2番目のステップで取得し、それをサブクラスタイプのいずれかに変換して、残りの情報を入力します。これを行うための最良のアプローチは何でしょうか、そしてこれはNHibernateでも可能ですか？可能であれば、元の文書記録を保持したいのですが、それを投棄しなければならない場合、それは大したことではありません。

JPAプロバイダーとしてEclipseLinkを使用しています。さらに、次のTABLE_PER_CLASS継承構造を使用しています

問題は、親クラスのエントリのみを受け取りたいということです。ただし、名前付きクエリ「SELECT p FROM Parent p」を使用すると、子テーブルのすべてのエントリも返されます。

選択または検索コードは次のとおりです。

これにより、クエリは「SELECT pFROMParentp」になります。

この継承階層のすべてのエントリではなく、実際に親エントリのみを受信するにはどうすればよいですか？

つまり、すべての子エントリをそのままにして、親エントリのみを返すにはどうすればよいですか？

編集1：
EclipseLink 2.0.1を使用していますが、型式を使用してaxtavtのソリューションを試すたびに、次のエラーが発生します。

EclipseLinkの最新の安定バージョン2.1.1にも更新しましたが、問題は解決しません。

私は現在、3 つの異なる種類のビジネスのデータを保持するテーブルを含むブラウンフィールド データベースを使用しています。これは、SalesOrders と orderlines に関係しています。古いアプリケーションでは、各販売注文に 3 種類の注文行 (製品、時給、テキスト行) を追加できました。15 年前、これは Delphi で簡単なクエリを取得して 1 つのデータグリッド内のすべての行を取得するための迅速かつ汚いソリューションでした。毎日

現在、NHibernate を使用して C# でオブジェクト モデルを構築しようとしています。これらの 3 つの線種には実際のビジネス論理接続がないため、基本クラスなしで 3 つの別個のエンティティを作成しました。ただし、これらの 3 つのタイプを 1 つのリストにまとめて、注文できるようにしたいと考えています。

テーブルが要件を満たしているため、継承、クラスごとのテーブルの使用を検討しました（null以外の制約を持つ列はありません）。ただし、タイプごとのビジネスはまったく異なるため、これは論理的なステップではありません (共通するのは、userId、説明、およびコメントのみです)。もしかしてコンポーネント？しかし、基本クラスやテーブル名以外のリンクなしで、プロパティを3つの異なるクラスにマップする方法は?

皆さんが私が書いたことを理解してくれることを願っています。私はまだ実際のコードを持っていません。このコードの扱い方を紙にスケッチしているだけです。

ここに誰か助けてくれる人はいますか？

よろしく、テッド

次の階層があります

Tr が両方の具体的なサブクラスへの参照を持つクラスもあります

上記のように定義されたクラスを使用すると、遅延読み込みが正常に機能します。

しかし、多態的なクエリを実行しようとしてもうまくいきません:

エラーが発生します：

注文がマッピングされていません

この投稿に基づく: http://java.dzone.com/articles/jpa-implementation-patterns-mapping

ところで、Hibernate プロキシを使用する場合、上記の 3 つの戦略のいずれかでマップされたクラスを遅延ロードすると、常にスーパークラスのインスタンスであるプロキシが返されることに注意してください。引用符

これは、私が見ている奇妙な動作と一致します。

ただし、ここからが奇妙になります。親クラスを

つまり、MappedSuperClass アノテーションをコメント アウトすると、ポリモーフィック クエリが機能します (正しいユニオンが作成されます)。問題は、Tr から 2 つのサブクラスへの LAZY ロードが機能しなくなることです。

何か案は？JPA の代わりにネイティブ クエリを使用してユニオンを実行できますか?

Hibernateを使用してJBoss 6.0.0でJPA 2.0を使用しています-JBossに同梱されているバージョンは何でも

私は次のシナリオを持っています

マッピングには、次のコード スニペットを使用しました:-

デフォルトでは、流暢は BaseClass である抽象基本クラスを無視します。しかし、クラスProcessStepにはIListを返すプロパティ ContentElements があるため、例外が発生します:- NHibernate.MappingException : 関連付けがマップされていないクラスを参照しています: BaseClass

IncludeBase(typeof(BaseClass)) を使用して基本クラスを含めると、正常に動作しますが、BaseClass および Derived クラスのテーブルが作成され、レコードは FK-PK 関係 (サブクラスごとのテーブル) にリンクされます。私が達成したいのは、具体的なクラスごとのテーブルです。つまり、各派生クラスには独自のテーブルがあり、派生クラスのすべてのプロパティ + 基本クラスのプロパティがあります。それを達成する方法はありますか？

現在のプロジェクト（Java）用にデータベースを計画/設計しています。このプロジェクトでは、Hibernateを使用します。

私のプロジェクトには、Commandという基本クラス/インターフェイスがあります。実際、CommandクラスにはフィールドID（一意）のみが含まれています。

したがって、Commandのすべてのサブクラスに共通しているのは、一意のIDと、サブクラスによって実装されるexecuteというメソッドです。

MoveCommand、ResizeCommandなど、共通のデータフィールド（idを除く）を持たない多くのサブクラスが存在します。

例えば：

次に、コマンドのリストを含むDocumentという別のクラスがあります。

そのため、基本クラス「selectfromCommand」の多くのクエリが実行時に実行されました。

私の質問は、この場合、最高のパフォーマンスを得るには、どのような継承戦略を使用する必要があるかということです。

SQLの場合：この場合、JOIN（サブクラスごとのテーブル）またはUNION（具象クラスごとのテーブル）のパフォーマンスは向上しますか？

誰かがこのトピックの経験がありますか？

サブクラスごとのテーブルがより良い（設計）ソリューションになると思いますが、コマンドに共通するのはそれだけであるため、単一の列（id）を持つデータベーステーブルが存在するため、それについてはよくわかりません。