-S2Daoにむけて、ゴリゴリSQLが必要な理由

昨晩、会社の同僚と飲みながらO/RマッピングツールやEntityBeanではなく、SQLをハンドで書くS2Daoのようなソリューションが求められることを話してました。思いっきり話の前提を単純化すると、データベースというオブジェクト指向ではないものをオブジェクト指向ワールドに持ち込むとどうもよろしくないねというのがスタートポイントで、1)SQLの方言にそれぞれ対応していられないというようなことや、2)いつもおんなじようなJDBCハンドリングコード書いているねという問題を長く多くの開発者が抱えてきた歴史があります。これらの問題を解決するために出てきたのがO/RマッピングツールやEntityBeanだと思います。もちろんこれ以外も問題があり、その解決があるでしょうが、ここでは我田引水的にこれに話を絞ります。
さて、1)SQLの方言、これは悪いものなのか?私と同僚はこの方言というやつが大好きなんです。Oracleの方言大好き、Sybaseの方言大好き、そしてDB2の方言さえも。デカいDBまわすと何も考えずに書いたSQLだと結果が返ってこなくても、チューニングしたSQLだと早く返ってくるようなことがあるのです。また、DB2@AIXDB2@AS400では同じDB2で同じJDBCドライバですが、片方で早いものが片方では遅くなったりします。こういうのを知識と理論と少々の勘とでチューニングしてきます。また、採用してるDBって容易に変えませんから、DBのSQL方言に透過性を講じても有利なケースにめぐりあわなかったこともあります。Oracleの案件はOracleだし、Sybase使うなら上物が変ってもSybaseは変えません。
一方で2)JDBCのルーチンワーク、これはうんざりです。コンテナマネジメントのEntityBeanが登場したときはこのダルいコード(コネクションとってきて、SQL実行して、結果セットをループしながら値取得する。例外処理もネストさせるようなコード)を書かなくてもいいというだけで熱くなったものです。しかーし初期は動きが悪かったのと、アプリケーションサーバーが非常に高価だった。小規模・中規模の案件ではユーティリティ化したJDBCハンドリングクラスをたびたび作ってやりくりしてました。O/Rマッピングツールにはその登場からつい先日まで熱くなりました。結果セットをさくっとBeanにしてくれるのがうれしい。getString("UserName");だと、文字列で取得カラムを選択しますので、getUserName();というようなBeanのプロパティ取得とちがってバグが混入しやすいです。コンパイル時に終わらずに実行時に問題を持ち越したくなかったわけですね。しかし、O/RマッピングツールはやたらXML書いたりJavaDocコメント書いたり、Beanでクエリーをやってみたり。なんかなじまなかったのです。私や同僚の理想のソリューションとは何か?それは、
SQLを書く
・そのSQLJavaメソッドで呼び出す。SQLパラメータはメソッド引数を充てる。
・メソッドの返りはコレクションで、ループ(=フェッチ)するとBeanが得られる。
・書いたSQLのselect句のカラム名からリフレクションでBeanにプロパティセット。
・カラムとプロパティでの名前あわせはSQLの責任で"as"でもつかってあわせる。
・よってマッピング情報XMLは必要ない。
SQLは外部ファイルにできる。
・外部ファイルのSQLはそのままSQL*Plusとかで実行できる。


  
    
    SELECT lastname as user, age FROM customer
    WHERE user_id = /*S2*/7890/*user.id: integer*/
  

  

  
    
    
    UPDATE customer SET
    lastname = /*S2*/'masataka'/*user.name: string*/,
    lastupdate = /*S2*/'20040320'/*getFormat.format(now): string*/  
    WHERE user_id = /*S2*/7890/*user.id: integer*/
  

うーん、MLに投稿されていたひがさんの案をいじってみましたが、引数型とかうまくないな。あくまで妄想ということで。