Seasar Conference 2006 Spring (2)

前の記事 に続いてSeasar Conferenceをレポートする。

セッション1

  • DB-sideのほうは「PostgreSQLによる、ORマッピングvs SQL+ストアド 性能と生産性の比較研究」
  • Seasar-sideのほうは「JSFの波に乗れ! TeedaではじめるJSF
  • ミニセッションのほうは「S2JMS」「DI事始め」「DIベースのWindowsアプリの作り方」「Maple or S2Mapleデモ」

Teedaの情報はまたWeb+DB Pressあたりが流してくれるだろうし、それよりはPostgreSQLのほうの熱いタイトルに魅力を感じて、私はPostgreSQLのほうへ行った。内容はちょっと期待外れ。

まずは、PostgreSQLとユーザー会(JPUG)についての概略説明。MySQLとの簡単な性能比較とか。概略といってもこれが長い。Teedaを捨ててまで敢えてこっちを聞きにくる人間なら、それぐらい知ってるって。勘弁して欲しい。

概略説明

まぁ、雑誌にいくらでも載ってる情報だけど、一応、一部はメモ取った。

  • 中心的コミッタが一度には失業しないように、コアメンバーは全員違う会社に所属するようになっている
  • 基本的に、標準準拠指向かつ高機能指向なので、下記を除けば「これはできる?」と聞かれるようなことは大体できる。

  • レプリケーションクラスタ化。ただし、pgpoolとかslony-lとか外部ツールはある。

  • ライブラリ動作モード。サポートするのはクライアント - サーバーモデルのみ。
  • クエリキャッシュ
  • トランザクションの隔離レベルは2つだけしか実装されていない。どれとどれだっけ。まぁ、調べればそこら中に書いてある。

  • MySQLと比較して、

  • SELECTは同じくらい

  • コネクションを張るのが遅い。接続に対してMySQLがthreadを立ち上げるのに対し、PostgreSQLはプロセスを立ち上げるため。
  • JOINが増える程、PostgreSQLが速い
  • 全体としてあんまり変わりはない。あとはケースバイケース

  • 8.0の見どころ

  • PITR。

  • Windowsネイティブサポート

  • 8.1の見どころ

  • 2 phase commit

  • SMP性能向上。従来はマルチCPUを有効に活用できていなかったが、ロックの粒度を細かくして対応した。

モデリング手法について復習

プロセス指向、データ指向、オブジェクト指向。関連する様々な分析法、設計法。それらの変遷、歴史について。これが10分。えーと、ここに来てる人なら知ってると思うよ。

本題

ここから先の20分は面白かった。

何故インピーダンスミスマッチが発生するのか

  • 10年前から決定打は無い
  • 単にクラス図をテーブルに落とすなら、マッピング手法は確立されている

難しいのは、オブジェクトのライフサイクル、永続性分析。

  • 「デザイン上こうするのが自然だよね」とはならない
  • 極端な話、普通ならHTTPセッションに入れるような情報を全部DBに入れても良い筈。
  • デザイン上の必然性は無いけれど、パフォーマンス面からあるものはDBに入れ、あるものは入れない。
  • 決定材料が不足するところに判断を下さなければならないので難しい

事例1: 携帯向け, Servlet/JSP + Oracle 10g

オブジェクトが長く参照されるのに、テーブル単位で個々にDTOとしてアクセスして、それらをJavaプログラム側でいじくり回していた。所謂Bean Managed Joinsアンチパターン?

ORMの利点(?)

ORMは

  • 曰く、インピーダンスミスマッチを吸収する
  • 曰く、ロジックの中にSQLを混ぜ込まなくてよい
  • 曰く、特定のDBMSへの依存性を吸収できる
  • 曰く、Connectionの確立等の定型部をいちいち書かなくてよい

ここで疑問を提示する。

  • それってDAOパターンの利点でないか?
  • SQLが嫌いなだけじゃないか?

それに、DBプログラミングではトランザクション設計はテーブル設計と同じぐらい重要。

こういう判断が必要。そして、

で、こういう問題をORMがどう解決してくれるって? 

SQLは昔風に言えば第4世代言語な訳で、データを取り扱うことに関して生産性は高い。そもそも、ビジネスロジックというものはSQLで完結する筈だ。プログラム言語は、SQL発行に至るまでの外部インターフェースを整えるに過ぎない。

……だそうです。

歴史的にSQLこそがビジネスロジックであったのだと、その辺を語ってたのは 羽生さんの本 だっけか。

提案

とりあえずの解決策として粒度大きめのDAOを使おう。

また、プログラム言語へのHTMLへの混在をJSPが解消したように、テンプレートベースでSQL混在を解消すれば良い。

あとは、ビジネスロジックの記述にストアードプロシージャを使おう。

事例2: クライアント - サーバー, PHP + PostgreSQL 7.3 + Delphi

PL/pgSQLが7000行。このストアードプロシージャ群がクライアントとサーバーの間に入ってビジネスロジックを抽象化した。

  • ストアードプロシージャは運用中に書き換えが効くのが役に立った
  • PostgreSQLではストアードプロシージャはトランザクションを跨げないのがちょっと難点。

S2Dao体験

講演者の高塚さんは、Seasar歴1ヶ月弱だそうですが、ちょっと触ってみての感想とのことです。

  • S2Daoは、メソッドに任意のSQLを割り当てられるのが良い。

  • OR Mapperとしてだけでなく、SQLテンプレートフレームワークとしても使える

感想

後半だけでいいよ。

続く

セッション2