June 18, 2007.

O/Rマッピング

コンテンツ作成は漸進中です。この「漸」という字がお気に入りです。一番目にするのは漸近線と書くときでしょうか。どうでもいい話ですが。さて、昨日またJava関係のコンテンツを追加しました。Eclipseのコンテンツを追加しようとしたら、packageの命名に関して説明が必要となり、旧サイトのコンテンツの移植も同時に行ないました。Eclipseの説明の概要が進まないとplug-in関係のコンテンツがかけません。面倒ですが、現役を退いた身としてはいいリハビリになりそうです。実務ではまったく使わない技術なので、空き時間にまったりと進めて生きたいと思います。

Java上でRuby on Railと同様にO/Rマップを実現するモジュールにHibernateというものがあります。JavaでO/Rマッピングと言えばHibernate!!...だった時代も有ったのですが、どうも最近ではそうでもないようで。

元々「xml==遅い、面倒」「自動生成==遅い、不便」と二つの爆弾を抱えていたHibernateですが、xmlの自動生成や、速度が必要な箇所で独自のHQL(SQLもどき)を組む事ができるなど回避策も準備されていました。しかし、久し振りに勉強しようと検索してみると、そこかしこで遅い、使えないと酷い叩かれよう。最新版を自分の目で確認したわけではないので、具体的にはHibernateの記事を書く際に取りまとめたいと思います。しかも、tw氏に「訴訟起こされてるよ」という話を聞いて、調べたところ、やられてますねぇ。SunのJ2EEにだって同様の技術は使われてるわけで、勝てばより儲かりそうだけど、立場が悪くなるSunには立ち向かわないあたりに訴えている側のずるさを感じます。Hibernateが負けた場合、訴訟を起こされる前にSunがお金を払う、など穏便な解決が選択され、喧嘩せずにお金を儲けられるのではないかという算段でしょう。

ところでO/Rマップというと、遅くて使い物にならないと言う評価ですが、baristaは「場合によっちゃあり」と考えています。条件は「新規システムである事」でしょうか。少なくとも、びっくりするぐらい大きな日本企業のDBサーバをHibernateで読み書きするプロジェクトに参加したことがあるので。速度的有利不利はともかく、使えなくは無いのでは(希望的観測)。なんせ、導入開始までに別の客先に行ったので....。

設計の面から言うと、正規化よりも読み取り速度を重視し、冗長性を持たせてやれば、Read側はO/Rマップでの実装が可能なのではないか、と想像しています。あくまで想像で、実際に設計に落としていないので、保障はできませんが。

で、舌の根も乾かないうちに自己反駁。O/Rマップの利点をあげるなら「速度より、メンテナンス性」という思想に基づいたものになるでしょう。ところが、xmlによる記述はプログラム言語から離れるため、どれだけツールが発達してもコードに直書きするより、ロジックチェックがおろそかになり、メンテナンス性は低下します。baristaの経験上、.ini, .config, .xml, .psp ... こういうファイルがプロジェクトのデバッグ作業を困難にしています。したがって、O/Rマッパを擁護しつつ、baristaはxml嫌いです！(鬼

でも、O/Rマップをやめ、SQL記述したところで、プログラム中のSQLもデバッグがしづらい箇所の一つなわけで、結局のところテーブル設計が最重要なのではないか、という結論にしかたどり着きません。何気なくデータを正規化してテーブルに起こすのではなく、用途を考え、更新しやすい・同期しやすい・読み取りやすい、そいういう設計をすべきでしょう。

真のO/Rマップとはテーブル設計時に脳内で行なうもの也！

...って、設計者の能力への依存度が低いのがフレームワークの(略

Copyright 2007 barista. All rights reserved.