Java + JPA / Hibernate + Mysqlの具体的なケースを求めていますが、この質問は多くの言語に適用できると思います。
従業員などのエンティティを取得するために、データベースに対してクエリを実行する必要がある場合があります。特定の従業員（名が「John」の従業員）が必要だとしましょう。この正確な従業員のセットを返すクエリを実行するか、すべての従業員を検索してからプログラミング言語を使用して取得します。あなたが興味を持っているものは？なぜ（使いやすさ、効率性）？（一般的に）どちらがより効率的ですか？
テーブルのサイズに応じて、一方のアプローチがもう一方のアプローチよりも優れていますか？
考慮事項：
常にデータベースに対してクエリを実行します。そうしないと、より多くのデータをクライアントにコピーする必要があり、データベースはデータを効率的にフィルター処理するように記述されており、コードよりも効率的であることはほぼ確実です。
私が考えることができる唯一の例外は、フィルター条件が計算的に複雑で、データベースが持つよりも多くの CPU パワーに計算を分散できる場合です。
私がデータベースを持っていた場合、サーバーはクライアントよりも多くのCPUパワーを持っていたので、過負荷でない限り、同じ量のコードに対してクエリをより速く実行します.
また、Hibernates クエリ言語を使用してデータベースでクエリを実行するためのコードを記述する必要が少なくなり、クライアントでデータを操作するコードを記述する必要がなくなります。Hibernate クエリは、追加のコードを記述する必要なく、構成内のクライアント キャッシュも利用します。
プログラミングでよく使用される一般的なトリックがあります。操作の高速化のためにメモリを支払うことです。多くの従業員がいて、そのかなりの部分を 1 つずつクエリする場合 (たとえば、75% が一度にクエリされるとします)、すべてをクエリしてキャッシュします(非常に重要です!)。メモリ内のルックアップを完了します。次にクエリを実行するときは、RDBMS への移動をスキップして、キャッシュに直接アクセスし、高速なルックアップを実行します。データベースへのラウンドトリップは、インメモリ ハッシュ ルックアップに比べて非常にコストがかかります。
一方、従業員のごく一部にアクセスしている場合は、1 人の従業員だけにクエリを実行する必要があります。RDBMS からプログラムへのデータ転送には多くの時間がかかり、多くのネットワーク帯域幅と大量のメモリが必要になります。 RDBMS 側の大量のメモリ。多くの行をクエリして、1 つを除いてすべて破棄することは意味がありません。
一般に、データベースが得意とすることはデータベースに任せます。データのフィルタリングは、データベースが得意とすることなので、そのままにしておいた方がよいでしょう。
とはいえ、それらすべてを取得して、コードでフィルタリングを実行したい場合もあります。私が考えることができるのは、行数が比較的少なく、それらをアプリにキャッシュする予定がある場合です。その場合、すべての行を検索してキャッシュし、キャッシュにあるものに対して後続のフィルタリングを行うだけです。
アプローチは時間の経過とともにスケーリングする必要があることを忘れないでください。小さなデータ セットかもしれないが、時間の経過とともに巨大なデータ セットに変わる可能性があります。テーブル全体をクエリしてから操作を実行するようにアプリケーションをコーディングしたプログラマーに問題がありました。2 つの副選択がある 100 行しかない場合、このアプローチはうまく機能しましたが、データが年々増加するにつれて、パフォーマンスの問題が明らかになりました。日付フィルターを挿入して過去 365 日間のみをクエリすることで、アプリケーションのスケーリングを向上させることができます。
状況次第です。一般に、正確な結果セットを取得するには sql を使用する方がよいと思います。
すべてのエンティティをロードしてからプログラムで検索する場合の問題は、すべてのエンティティをロードする必要があり、多くのメモリを消費する可能性があることです。さらに、すべてのエンティティを検索する必要があります。RDBMS を活用して、必要な正確な結果を得ることができるのに、なぜそれを行うのでしょうか。つまり、RDBMS に作業を任せることができるのに、大量のメモリを使用する可能性のある大規模なデータセットをロードしてから処理する必要はありません。
一方、データセットのサイズがそれほど大きくないことがわかっている場合は、それをメモリにロードしてクエリを実行できます。これには、RDBMS にアクセスする必要がないという利点があります。システム アーキテクチャによっては、ネットワークを経由する必要があります。
ただし、その場合でも、さまざまなキャッシュ ユーティリティを使用して、共通のクエリ結果をキャッシュすることができます。これにより、データを自分でキャッシュする利点が失われます。
-休止状態に固有の回答を探している場合は、@Markの回答を確認してください
従業員の例を考えると、従業員の数が時間の経過とともに拡大する可能性があると仮定すると、正確なデータをデータベースに照会するアプローチを使用することをお勧めします。ただし、たとえば、データが急速に増加する可能性が少ない部門のようなものを検討している場合は、それらすべてにクエリを実行してメモリに保存しておくと便利です。これにより、外部にアクセスする必要がなくなります。毎回リソース（データベース）が必要になるため、コストがかかる可能性があります。
したがって、一般的なパラメータは次のとおりです。
ある意味では、データが頻繁にスケーリングされず、データがミッションクリティカルではなく、データの量がアプリケーションサーバーのメモリで管理可能であり、頻繁に使用される場合-必要に応じて、すべてを持ってきてプログラムでフィルタリングします。
それ以外の場合は、特定のデータのみを取得します。
家にたくさんの食料を蓄えておくのと、少しずつ買うのとでは、どちらが良いでしょうか。旅行が多いときは？パーティーを主催するときだけですか？場合によりますね。同様に、最良のアプローチは、パフォーマンスの最適化の問題です。それには多くの変数が含まれます。技術は、ソリューションを設計するときに窮地に追い込まれないようにすることと、実際のボトルネックがわかった後で最適化することの両方です。良い出発点はここにあります: en.wikipedia.org/wiki/Performance_tuning 多かれ少なかれ普遍的に役立つと思われる 1 つの考えは、データ アクセスを適切にカプセル化することです。