読者です 読者をやめる 読者になる 読者になる

ResultSet(2)

Java Program

ResultSet - ぐるぐる〜への反応への反応。

あと、ResultSet にはカーソル的な更新の API もかねているのと、その際のエラー情報取得とかあったり。

JDBC と Collection API - odz buffer

あー、カーソルとしてのResultSetを完全に失念してました。ただ、個人的にカーソルという考え方そのものに否定的*1なので、結果を表すクラスと一緒というのはかなり気持ち悪いです。というかResultSetが結果を表していると考えているほうが間違いなのか*2

なんでもかんでも、On Memory にしようとしたら100万行のテーブルをカーソルで操作、とかなるとえらいことになるし*1。

JDBC と Collection API - odz buffer

確かに、CollectionにしてしまうとOn Memoryになってしまうのは痛いですね。出来る限りSQL側で削るといっても、ありえない状況じゃないですからね。
ってことはCollection的なAPIにするよりも、やっぱりIterableを継承したほうがまだ現実的ですね。

public interface Cursor extends Iterable<Object> {
    ....
}

的な。でもこうすると例外に頭を悩ませないといけない・・・
うーん、八方塞ですね。

直接結果の件数を取得する API がない (last で移動して getRow を 呼ぶという workaround)こと

JDBC と Collection API - odz buffer

これについては、count(*)で数える、という方法もありますが、どっちにしてもいい方法とは言いがたいですね。

あと、まぁ S2DAO なり Hibernate なりの O/R Mapper を使うとか、そこまででもなければ Apache Commons DbUtils の QueryRunner を使うってのがいいんでないかなぁ。

JDBC と Collection API - odz buffer

それはそうなんですが、使いたくても使えない状況というのが・・・


あと、個人的にはDAO、DTOっていうのがそもそも気に入らないんですよねぇ。インピーダンスミスマッチを解決し切れてないというかなんというか。とくにDTOはミスマッチを解決しているんじゃなくて、ObjectモデルをRelationalモデルに合わせているようにしか思えません。なんでRelationalモデルで設計したテーブル1つにつき1つのクラスを用意しなきゃいけないんだよ、と*3 *4


生のJDBCに関しては、タイプセーフ性の問題もどうにかならんものかと思っていて、.NET Framework 3.5のLINQなんかはこれに対する解決策になるのかな、とか考えて妄想してます。ただ、シーケンシャルなデータ構造までSQL的な手段で操作できてしまえるなんていうのはどうかと思うんだけど*5


結局、ResultSetについてあーだこーだ言って来たけど、これはもう公布されてしまったインターフェイスだから、どうにもならんのが現実なんだよなぁ。機能を追加するか、ライブラリやフレームワークで隠蔽するしかない。
JDBCはライブラリやフレームワークからしか使わないAPIと思っておいたほうがいいのかな*6

*1:だけど他にいい案があるかというと、何もありませんw

*2:イテレータ的とか言ったけど、そうじゃんカーソルじゃん

*3:自動生成できるけど、それは最善の方法じゃぁないんじゃないかな

*4:逆に、Objectモデルを意識してテーブルを作ると、RelationalモデルをObjectモデルに合わせていることになる(しかもこっちの場合はかなり不完全)

*5:まぁ、そこはC#っぽいといえばC#っぽいけど

*6:腑に落ちないなぁ・・・