実際には何が良いですか？たとえば、ネストされたオブジェクトをロードする責任がある複雑なクエリを持つクラスを持つことはできますか？単純なオブジェクトの読み込みを担当する簡単なクエリを持つクラスですか？1つの複雑なクエリ対複数の単純なクエリ
複雑なクエリでは、データベースに行く必要はありませんが、クラスの責任はますます大きくなります。
さらにデータベースにアクセスする必要のある簡単なクエリです。この場合、各クラスは1つのタイプのオブジェクトの読み込みを行います。
私がいる状況は、読み込まれたオブジェクトがFlexアプリケーション（DTO）に送信されるということです。
ゴーの簡単な方法である限り、パフォーマンスを最適化するために何の実績のある理由がないとして：私が言うの直感から
ここでの一般的な経験則では、サーバーのラウンドトリップは高価であり（典型的なクエリの所要時間に比べて）、誘導の原則は最小限に抑えたいということです。基本的には、1対多の結合では結果セットが増えてしまうので、これにアプローチする方法は、結果セットが大きくなりすぎたり、クエリの実行時間が長くなりすぎるまで（一般的には1〜5秒程度）
プラットフォームによっては、クエリを並行して実行する場合と実行できない場合があります。これは、一度に1つのクエリしか実行できない場合、クエリを分割する障壁がはるかに高いため、実行すべき主な決定要因です。
ある一定の比較的一定したデータをメモリ（国の情報など）に保存するか、個別にクエリを実行する価値がありますが、これは私の経験上、合理的に珍しいことです。
もっと一般的なことは、ジョインの代わりに別々のクエリ（特に相関クエリ）を実行することによって、ひどいパフォーマンスでシステムを修復することです。
。さもなければ、私は早すぎる最適化のバスケットに「複雑なオブジェクトとクエリ」アプローチを置くでしょう。
実際のパフォーマンスに影響がある場合は、次のステップでフレックスとバックエンドの間のラウンドトリップを最適化する必要があります。しかし、私が前に言ったように：これは腸の感覚です、あなたは本当に "performant"の定義から始めて、簡単に始めて、パフォーマンスを測るべきです。
私はどのオプションも実際にはとは思えません。です。これは、アプリケーション固有のアーキテクチャ、使用されているDBMSおよびその他の要因によって異なります。
など。私たちはスタンドアロンソリューションで複数の簡単なクエリを使用しました。しかし、私たちの製品が軽量のインターネットアクセス可能なソリューションに向けて進化したとき、私たちのフレームワークは膨大なリクエストを出し、ネットワーク待ち時間のパフォーマンス原因を殺したことがわかりました。そこで、集約された複雑なクエリを使用するためのフレームワークを十分に修正しました。一方で、スタンドアロン・ソリューションを維持し、Oracle LightからApache Derbyに移行しました。もう一度、我々の新しい複雑なクエリのうちのいくつかは、Derbyがそれらをあまりにも長く実行したために単純化されるべきであることがわかりました。
実際の問題を見て、適切に解決してください。私は、単純なクエリは、それに対して強い目標がない場合には、最初に良いと思う。