O/Rマッパー

たとえば画像を扱うのに、ピクセルをクラス化してもあんまり有用じゃない。効率最重視のC++ですらそれは悪い選択だ。オーバーヘッドが大きくなるばかりで、クラス化によって得られる利点は別の方法でも代用できる。たぶん「画像はピクセルの集合である」というのが重要な性質だからだろう。

表計算なんかでも同じで、例えばMS OfficeのCOM APIなんかもやっぱり、セルそのものはオブジェクト化していない。ほとんど常にデータの集合を意識して操作を行う仕組みになっている。

で、今回はO/Rマッパーのお話。今の職場でO/Rマッパーを使うことになったんだけど、それほど面倒じゃない奴だったので少し助かった感じだ…。

たいていのO/RマッパーはRDBSをオブジェクトを保存する場所としか思ってなくて、集合に対する操作って側面はサポートしてない。もし本当に集合に対する操作が必要ないなら、バックエンドはkey-valueストアで十分かもしれない。memcached互換の永続kvストアもいくつかあるし、場合によっては最適かもね。

RDBSの利点は集合を集合のまま操作できることだ。O/Rマッパーでカバーできない領域はむしろSQLを書いた方が都合がいい。集約計算のような操作はDBサーバ側で完結していた方が都合がいいし、余計な層を挟むと最適化がやりにくくなる。

O/Rマッパーはコンパイル時のエラー検出が強力な言語では便利だったかもしれないけど、クラスを書かなくても複雑なデータ構造を表現できる言語だと、O/Rマッピングそのものには便利さを感じない。無名ハッシュでいいじゃん。何が困るの。

使うにしても資源へのアクセスに対するエラー処理を忘れてしまうのは問題だと思う。

じゃあそういうレイヤーは不要なのかというと、そうも思っていなくて、キャッシュやデータパーティションのサポートを行う層としてはそれなりに便利なのかもしれない。

• 「SQLレス」は冗談としか思えない。O/Rマッパーではできない操作は多い。
• O/Rマッパーに甘えてエラー処理をサボったコードは運用の敵
• オーバヘッドがバカにならないことは意識するべき？