たとえば、次のエンティティとリレーション構造を持つDBがあります。
[人]には[スキル]がたくさんあり、[スキル]には[アクション]がたくさんあります
.hbm.xmlでは、人>スキル、スキル>アクションに1対多の関係を割り当てます。
クエリでは、Personにクエリを実行するタイミングを制御して、スキルのみを熱心にロードできるようにしたいと思います。現在、私は何もロードせず、人のスキルを取得するためにn + 1の量のクエリを生成するか、全体を熱心にロードするために（n * n + 1）の量のクエリを生成することに行き詰まっているようです。個人>スキル>アクションコレクションの階層。
3番目の深度テーブルをロードするタイミングとロードしたくないタイミングを制御できるように制限するにはどうすればよいですか？コンテキストとしては、Person> Skillsコレクションを常に初期化して、理想的にはn+1のパフォーマンスのボトルネックを防ぐためのJOINとして生きることができます。
私は次の方法を使用します。
特に子コレクションに多くのエントリが含まれる可能性がある場合は、オブジェクトの子コレクションを避けようとします。子供を取得する必要がある場合は、クエリを使用して子を取得します。
子コレクションがある場合は、常にコレクションを遅延ロードするように設定します。
'querying'の場合、Criteria APIを使用して、クエリを作成し、実行して結果を返すクラスがあります。クエリの作成の一環としてroot.fetch(Person_.skills);、rootがjavax.persistence.criteria.Root<Person>必要なコレクションを熱心にロードする場所を使用します。
少し話題から外れていますが、RDBMSやHiberanteの代わりに、グラフデータベースの実装を使用して、このようなレベルの複雑さのデータを維持することを検討してください。グラフデータベースであるneo4jを参照してください。これにより、ノード（この場合は人、スキル）とノード間の関係（拡張、認識）を作成できます。したがって、あらゆるレベルの深さでデータを簡単にトラバースできるようになります。
これは、実行時に非常に簡単に制御できることがわかりました。
私の.hbm.xmlで、私は自分のアソシエーションセットを怠惰であると宣言し続けました（さらに怠惰です！）。
HQLクエリでは、次のようにクエリを実行します。
Select distinct p from Person
left join fetch p.skills
キーワードはfetch、その特定の結合に対して積極的な読み込みを強制します。