多数のレコードを選択し、外部システムに送信するファイルをフォーマットすることを含む、毎日のバッチプロセスがあります。また、これらのレコードを送信済みとしてマークして、明日再送信されないようにする必要があります。
私の素朴なJDBCの方法では、ステートメントを準備して実行してから、レコードセットのループを開始します。レコードセットを進めるだけなので、アプリケーションサーバーが結果セット全体を一度にメモリに保持する必要はありません。レコードのグループは、データベースサーバーからフィードすることができます。
ここで、Hibernateを使用しているとしましょう。一度にメモリ内の結果セット全体を表すオブジェクトの束になってしまうのではないでしょうか。
Hibernate も結果セットを反復処理するため、1 行のみがメモリに保持されます。これがデフォルトです。貪欲にロードする場合は、そのように指示する必要があります。
休止状態を使用する理由:
Hibernate を使用しない理由:
Hibernate は、セッションを小さく保ついくつかの可能性を提供します。
JDBC のようなスクロールには、Query.scroll()、Criteria.scroll() を使用できます。Session.evict(Object entity) を使用して、セッションからエンティティを削除できます。StatelessSession を使用して、ダーティ チェックを抑制することができます。さらにパフォーマンスの最適化がいくつかあります。 Hibernate のドキュメントを参照してください。
ORMフレームワークは、オブジェクト指向プログラミングプリンシパルに基づくシステムの開発と保守を目的としているため、休止状態になります。ただし、ほとんどのデータベースはリレーショナルであり、オブジェクト指向ではないため、いずれの場合でも、ORMは常に便利なOOPプログラミングと最適化された/最も効果的なDBアクセスの間のトレードオフです。
私は特定の分離されたタスクにORMを使用するのではなく、アプリケーション永続化レイヤーの全体的なアーキテクチャの選択として使用します。
私の意見では、Hibernate は使用しません。アプリケーションが大きくなり、保守性が低下し、生成された SQL スクリプトを迅速に最適化する機会が実際にないためです。さらに、JDBC ブリッジがサポートするすべての SQL 機能を使用でき、ハイバネート機能に限定されません。もう 1 つのことは、レガシー コードの各レイヤーに伴う制限もあるということです。
しかし、最終的には哲学的な問題であり、自分の考え方に最も適した方法で行う必要があります。
パフォーマンスの問題が発生する可能性がある場合は、JDBCコードを使用してください。
Hibernateで実行するのが非常に難しい、よく知られている純粋なSQL最適化がいくつかあります。
使用する列のみを選択してください。（「select *」のものはありません）。
SQlを可能な限りシンプルに保ちます。例：結合に通貨コードのような小さな参照テーブルを含めないでください。代わりに、通貨テーブルをメモリにロードし、プログラムルックアップを使用して通貨の説明を解決します。
DBMSによっては、述語がパフォーマンスに大きな影響を与える可能性があるSQLのマイナーな並べ替えがあります。
更新/挿入する場合は、100〜1000回の更新ごとにのみコミットします。つまり、すべての作業単位をコミットするのではなく、コミットする頻度を減らすためにカウンターを保持します。
データベースの集計関数を利用します。DEPTコードによる合計が必要な場合は、SQLで「SUM（amount）...GROUPBYDEPT」を使用して実行します。