SQL RDBMS：1つのクエリまたは複数の呼び出し
インターネットを見回した後、呼び出し側のビジネスロジック関数/メソッドにオブジェクト（POJO）を返すDAOを作成することにしました。
たとえば、Address参照を持つCustomerオブジェクトは、RDBMSで2つのテーブルに分割されます。顧客と住所。 CustomerDAOは、2つのテーブルのデータを結合し、アドレスをカスタマーオブジェクトに追加するアドレスPOJOおよびカスタマーPOJOの両方を作成します。最後に、完全なCustomer POJOを返します。
単純ですが、今では、3つまたは4つのテーブルを結合する必要があり、それぞれが結果のPOJOの属性または属性のリストを表します。 SQLにはgroup byが含まれますが、一部のテーブルが1対多の関係を結合しているため、同じpojoに対して複数の行が生成されます。アプリコードは、行が異なる属性で同じであるか、またはレコードが新しいPOJOである必要があるかどうかを判断しようとして、すべての行をループする必要があります。
この手法を使用してdaosを作成し続けるか、Pojoの作成を複数のdb呼び出しに分割して、コードを理解し、維持しやすくする必要がありますか？
正しさを第一に考えるべきです。データ構造を作成して、問題のドメインを正しく効果的な方法でモデル化し、コードを簡単に操作できるようにします。
それを超えて、特にデータベースがローカルでない（それを呼び出すプログラムと同じマシン上にある）場合は、データベース呼び出しを最小限に抑えるようにしてください。ここでのネットワーク遅延は実際の考慮事項であり、重要な場合があります。
10のデータベース呼び出しを必要とする操作があるとします。ネットワークの待ち時間が100ミリ秒の場合、この操作には、サーバーとの通信だけで1秒の純粋なオーバーヘッドがかかり、実際に関連する作業を行うのにかかる時間もかかります。待ち時間が1秒の場合、ネットワークの待ち時間だけで10秒を無駄にします。しかし、それを10の呼び出しから1に減らすと、非常に醜い遅延状態でも突然、ネットワークのオーバーヘッドに多くの時間を費やすことはありません。
一般的な経験則として、単純にデータを取得するだけで（データベースサーバー内またはクライアント上でデータを大量に処理しない場合）、はるかに最大のボトルネックになりますローカルデータベース以外のシステムでは、ネットワーク遅延が発生します。したがって、呼び出しの数を減らすことができれば、それを取得した後でクライアント側で追加の作業を行う必要がある場合でも、おそらく先に出てくるでしょう。
いつものように、最適化の最も重要なルールを覚えておいてください：最初に測定！今説明したような経験則ではなく、ハードデータで最適化しないと、簡単に多くのハードワークを実行してしまう可能性があります。それは物事を遅くします！ただし、一般的には、クエリの数を抑えることが通常は最善の方法です。
クエリが予想よりも多くの行を返す場合、クエリの記述は不適切です。
Customer POJOのデータを取得するには、クエリを実行する必要があります。そのクエリは単一の行を返す必要があるため、DAOは単一のPOJOを入力します。
次に、2番目のクエリが実行され、外部キー（顧客ID）を指定して、「多数」のテーブルから行を取得し、行が見つかったのと同じ数のPOJOSを作成します。次に、そのアドレスオブジェクトのリストが顧客のPOJOに割り当てられます。
Customerクラスには、タイプList<Address>.のメンバーがあります
DBアクセスの負荷が高い場合は、遅延して実行できます。つまり、getAddress of getAddressListが最初に呼び出されたときにのみアドレスをフェッチします。
同じ手法を、DBから読み取られるCustomerクラスのすべての集計または構成に使用できます。
編集：
パフォーマンスについて：CustomerテーブルにはPK（おそらくcustomerID）が必要なので、最新のRDBMSを使用している場合、行の取得は非常に高速でなければなりません。また、子テーブルにはPK、および親テーブルのPKを指すFKが必要です。そのFKにもインデックスが付けられます。これは、RDBMSが作成される非常に基本的なタスクのようなものです。
アプリサーバー（またはクライアントアプリ）と関連するDBサーバーの間のネットワークトラフィックについても、最適化できます。
ポイントは：
ハードウェアと輸送の問題は、その時点でお金を払うことで解決できます。
複雑さの問題 RDBMSがより効率的に行うことを行うコードを記述することから派生それらにお金を投入することでは解決できません。
ハードウェアは安く、プログラマーは高額です。
SQLを使用してデータソースで正しい結合を実行した後（RDBMを使用している場合）、DTOの使用を検討することをお勧めします。さらに、複数の結果セットの概念を利用して、必要に応じて1つのサーバー呼び出しで異なるオブジェクトのセットを返すこともできます。
DTOはPOJOではありません（以下を参照してください： Difference-between-DTO-and-POCO -.NETについて質問していないことはわかっていますが、この議論の概念は似ていると思われます）。
このアプローチを使用すると、サーバーとクライアントの間で通信するデータが少なくなり、クライアントロジックで特別に手動で結合する必要がありません。私の知る限り、Javaは、 .NETのLINQ。
また、優れたORMを使用する（または知る）ことも検討してください。優れたORMは、おそらく実用的なアプローチを提供します。