オブジェクト指向言語と、RDBMS のインピーダンスミスマッチというのは昔からずーっと言われてきていて、最近ではいろいろなライブラリ、フレームワークのたぐいがそれを解消してくれるようになってきました。 しかし、この2つの組み合わせにはもっと恐ろしい弊害があるなと思っていて、自分の中で整理するためにもここに書いてみることにします。

RDBMS はエクセルなんかでおなじみのみためは２次元の表の集まり。 これをリレーションと呼ばれる表間のキー接続をつかって様々なデータを表していきます。

ここで問題となるのが、プログラムにおけるデータの持ち方とデータベースにおけるデータの持ち方が異なること。 特にオブジェクト指向でつくられたプログラムは RDBMS の２次元の表とデータの持ち方が異なり、データベース保存時に変換する必要があります。 そして、オブジェクト指向の場合、カプセルの単位がデータだけでなく"機能"も含まれます。

よくメンテナンスされたプログラムは、このインピーダンスミスマッチを O/R マッピングライブラリなどで解消し、そしてオブジェクトの持つ"機能のカプセル"部分もうまく再現できるようにつくられています。

そのへんが不出来なプログラムをみていて、思ったことがあるのです。

[tegaki]RDBMS がグローバル変数。[/tegaki]

オブジェクト指向の一番基本的な使い方は、同じ処理は同じところに書くこと。 継承などのオブジェクト指向特有の機能はそれを実現するためのツールです。

ところが、RDBMS のアクセスをいれたとたんそれが崩壊するときがあります。

それは、あちこちのモジュールからテーブルをアクセスし、データを書き換え、それを"モジュール間の連携手段"として動作させたとき。

同じたぐいの処理だったものが各モジュールに分散し、もはやオブジェクト指向の意味なし。 常に、各モジュールはデータベースのカラムの値を意識しなければいけない最悪。

不用意なカラムの書き換えは死を招き、調査にソースコードを全 grep する必要があり、恐ろしいアプリケーションに発展していきます。

まさにグローバル変数。

Java や C# などの言語は、たとえばグローバル変数を"使えない"ように言語体系でプログラマを縛ります。

言語はあるいみフレームワークとなり、無茶なプログラムが書けないようになるために、誰が書いても一定水準、メンテナンス製が高くなります。 また、できないことが分かっているため、修正等で考慮しなければいけない部分もぐっと減ります。

しかし RDBMS アクセスがはいり、それをたった１つの不適切なモジュールがした瞬間に、言語フレームワークの壁が崩壊してしまう印象があります。

モジュール間の連携で RDBMS を経由するのは、グローバル変数をつかってモジュール連携しているのと同じ意味です。 ソースコードの繋がりがそこでいっきに途絶えるので、特に MVC でつくられているプログラムは、処理シーケンスもデータフローもがソースコード上から読みとるのがとても困難で、また、読めた確証を持つ時間が大幅にかかります。

これはたとえ O/R マッピングのライブラリをいれても、プログラムの書きようでどーとでもなってしまう部分。 オブジェクト指向と RDBMS を組み合わせる場合最大のインピーダンスミスマッチ弊害なのかもしれません。

縛りを入れつつ、それを縛りとおもわせない解は RDBMS じゃなくて、オブジェクトデータベース使うことかなーって思うんですが、アプリをつかわずとも簡単にデータパッチできる RDBMS の運用性の高さ、信頼性、周辺ノウハウはなかなかおいそれと手放すわけにはいかず、歯がゆいところです。

"気をつけて書く" じゃなくて、書けないようにする。 窮屈ですが、人間考えることを少なくする方がいい結果を生むことも多いってもんです。 🙂