ResultSetとEntity、どちらが良いでしょうか？

Question

テーブルから取得して全件ループさせたいと考えています。

SELECT結果を
◆java.sqlのResultSetに格納する方法
と
◆Entityに格納する方法
が、実装方法として考えられます。

（他にも方法はあるのかなとは思いますが、今選択肢として目の前にあって悩んでいるのはこの二つです）

取得したら全件ループを行うという前提で、どちらを使えば良いという判断基準はありますでしょうか？

個人的には、ResultSetの方がメモリ消費量が抑えられるイメージなので、ResultSetが良いのかなと思っています。

（例えばEntityに100万レコード詰めて回したら確実にメモリエラーになりそうです。Entityのフィールドの数は8個くらいです）

よろしくお願い致します。

Comments

[momon-ga]

ご提示の二択で片やOutOfMemoryが出ることが、わかっているなら質問するまでもないのでは？

[m.ts10806]

環境やデータ次第かと思いますが、実際にメモリエラーになったのでしょうか？

[circular2016]

＞momon-gaさん
ResultSetの方が軽量なのであれば、常にResultSetが良いということになるのか？という点がわかりません。

＞m.ts10806さん
コーディングをしようとしている状況で、エラーにはなっておりません。環境はlinuxであることくらいしかわかっておりません。

よろしくお願いいたします。

[m.ts10806]

ではやはり、実際にやってみて決めては？
案ずるより産むが易し。

Answer 1

ResultSetの方が軽量なのであれば、常にResultSetが良いということになるのか？という点がわかりません。

実行結果を別のクラスに渡すかどうかで判断すればよいと思います。
ResultSetはSQLを実行したクラスでした基本的に型の情報がわからないので、使いづらいです。

戻り値としてResultSetを受け取ったクラスは、MetaDataを確認しないとアクセスできません。
もちろん投げたSQLがわかっていればというのはありますが、たぶんDBへのアクセスするレイヤーと
アプリケーションのレイヤーは異なるため、アプリ側でSQLを意識させることは無いかと思います。

ResultSetを引き回すっていうのは無通信の状態で切断されることもあるのでやめた方がよいです。

※まぁ、ここで悩んでるわけじゃないとは思いますが。

内部で完結するならば、ResultSetで問題ないです。
というか、わざわざEntityに詰め直すのは無駄です。
全件にたいして２重で走査（詰め直しと実処理）することになります。
もちろん懸念しているEntityに全部持つということは、その分のメモリーを消費するというのもあります。

処理時間的なことは気にしていないかもしれませんが
update系のSQLを発行するとか100万回のループを発生させないようにした方が良い気もしますが。
あとはパラレル実行をできるようにテーブル設計、アプリ設計をするとか。

以前、800万件の更新処理があったときは、updateでなくdrop-create＆lorderで対応したというケースがあります。

１件単位の処理を大量データにあわせてループさせるっていう考え方自体さけたほうが良いです。
パフォーマンスネックになるのが目に見えてます。

Answer 2

取得したら全件ループを行うという前提

確かにResultSetの方が軽量ではあります。

ただし、何らかのO/Rマッピングフレームワークにも行フェッチする機能は提供されているものがあり、場合によっては数百行単位でまとめて取得する機能を搭載するものもありますので、それで代替する選択肢もあるでしょう。

Answer 3

どちらの選択をしてもレコード数でメモリーエラーになるので、
どちらでも良いかと。

メモリ量を増やすか、
全件ではなくfetchするか、
という別の選択が必要になると思いますので。