「インピーダンスミスマッチ」の本質は何か(3)

O/Rマッピング

本来の（OOP登場以前から言われていた）インピーダンスミスマッチの意味は、ものすごくおおざっぱに言うと、SQLはバッチ処理だが言語はレコード指向でしか処理ができないことだった。
そんなミスマッチは埋めようがないじゃないの。
仮にOOPとRDBの間に埋められない溝があるのだとすれば、我々にできることはどっちかに寄せて使うことしかない。

のどっちかを選択するしかない。


本来、２つのうちどっちかを選ぶという議論は不毛なので、極力避けなくてはならない。
プロなら、社会人なら、大人なら、両立させる方法を生み出さねばならない（Entity Bean や index-only は、その解の一種だ）。
が、それは置いといて。仮に二元論的な考え方で行くとして、それぞれの立場のメリット・デメリットは何か。
いまのところの仮説はこう：

オブジェクト指向言語をオブジェクト指向言語的に使い、RDBを非RDB的に使う

言語を優先するアプローチでは、プログラムのエレガントさと生産性が向上し、パフォーマンスとデータ構造の変更に対する耐性が犠牲になりやすい。
設計が良くなるのだからメンテナンス性も上がりそうなものだが、お客さんのビジネスなり組織構造なりが変わった時に、上から下まで＝テンプレート・プログラム・DBのスキーマまで、全部が修正対象になるりがち。
例えば、顧客マスタメンテナンス機能に携帯電話番号の入力欄を追加する、という変更要望が来た場合。
全てがオブジェクトとして設計されているアプリケーションでは、プログラムの修正が発生する。それがJavaのWebアプリだったらコンテナの再起動が必要になる。

オブジェクト指向言語を非オブジェクト指向言語的に使い、RDBをRDB的に使う

RDBを優先するアプローチでは、設計がかっこわるくなり、生産性が低下するが、パフォーマンスとデータ構造の変更に対する耐性が得られる。
携帯電話番号を追加するケースでは、DBのスキーマとテンプレートの変更は必要だが、プログラムには手を触れなくてよい。コンテナの再起動は要らない。


で、自分はどうするかというと、パフォーマンスとデータ構造の変更に対する耐性を取る。
この２点を犠牲にすると、リリース後にお客さんから電話がかかってくることが多くなるから。
SIerなら誰でも、リリースしてからいろいろ言われることの大変さを知っているだろう。スケジュールが狂い放題になるのだ。
次のプロジェクトに全力を投入しなくてはならない時期に、過去のプロダクトに時間を取られるのはかなわない。
だが、パフォーマンス問題と、ビジネスの変更に連動するデータ構造の変更は、お客さんにとっては待ったなしなので、最優先で対応せざるを得ない。
お客さんにいろいろ言われることに比べれば、設計がアレで生産性が上がらないのは、社内の人間に嫌がられるだけで、どうということもない。


２つのうちどっちを取るかという考え方は思考停止的で、いい歳をしたおっさんの考えることとしては本来よくないことだ。
周りを見ればオブジェクト指向言語をオブジェクト指向言語的に使い、RDBをRDB的に使うを実現するためにたくさんの人が大変な努力をしている。EJB3.0もその成果の一つだろう。
しかし、それは無理なんだと割り切って、人の行かない道を進んでみたらどうなるか。
EJBは3.0になってもEJBなのだ。細木かずこなら即改名させるような、すごーく縁起の悪い名前が付いているのだ。
逆張りにも勝ち目はあるはずだ。


＃＃＃
読み返してみると、オブジェクト指向的な設計を貫徹するとシステムが変更に弱くなるという、聞き捨てならない話になっている。
ここは掘り下げて検討する予定。クラスの凝集性を上げるとオブジェクト間のデータの転記がやたらと発生するのですがみんなどうしてるの？みたいな話にもつながるだろう。