SQLer 生島勘富 のブログ

RDB・SQLの話題を中心に情報発信をしています。

SQLとオブジェクト指向言語の切替

SQLのイメージと他の言語のイメージ1
SQLのイメージと他の言語のイメージ2
 の続きです。

ユーザインタフェースとのアクセスはストアドプロシージャで。

 最終的に必要なシステムはこんな形だとします。

 RDBサーバにあるデータで作れる形はここまでだとします。

 ジオラマの背景やカラーリングはRDBサーバ内のデータでは表現できませんから、他のファイルサーバやWEBサービスマッシュアップする必要があるかも知れません。クライアント内の情報や、ユーザのリクエストと合わせる必要があるかも知れません。RDBサーバでできることは限られていて、それだけでシステムを完結することはできないわけです。

 最終的なシステムにするには、ボトムアップで考えるオブジェクト指向言語と、トップダウンで考えて行くSQLの両方を使っていく必要があります。

 もちろん、「多くの分かってない人」の主張通り、SQLを使って細かいパーツを削りだし、

 ボトムアップの考え方で作っていくことも可能です。しかし、そのやり方は生産性もパフォーマンスも非常に悪い。

 では、両方のいいとこ取りをするにはどうすればよいか。

 ジオラマを作るオブジェクト指向言語側から、こんな風な、

 (素のガンダムプラモデル)をくれたら、後はオブジェクト指向言語側でジオラマにレイアウトするよ。と要求すればよいのです。そのとき考えることは、SQLは表かスカラー値しか返せませんから、イベント(ユーザアクション)に対して、RDBサーバから1回か、2回のアクセスですむ形まで加工された、表かスカラー値を要求するわけです。表かスカラー値であれば、エクセルで簡単にスタブを作ることができます。このスタブはストアドプロシージャにしておけば、後のオブジェクト指向言語側の変更はゼロで済みます

 図でいえば最終のジオラマを作るのに、ガンダムが必要なのか、ザクが必要なのか、シャア専用ザクかを伝えればいい。

 これによりRDBMSとは完全に疎結合になります。

 オブジェクト指向言語だけでレイアウトとユーザインターフェース側だけを作るなら、オブジェクト指向言語が持つ再利用性の高さを存分に発揮することができます。また、IDEの機能や、フレームワークの機能が高くなってきていますので、ほんの少し訓練すれば顧客に作って貰うことも可能でしょう。結果的に、フレームワークを作る人ぐらいのレベルの高い人しか、技術者としての価値はなくなるかも知れませんが……。

現状のおかしさ。

 先ず、最終の姿とテーブルレイアウト(材料)から設計が始まります。


※ 材料(テーブルレイアウト)


※システムの最終の姿

 その後、それぞれの担当者に渡されますが、削り出しで行うSQL派と、部品を組み上げたいオブジェクト指向派がごちゃ混ぜにいて、どこまでSQLで行うかは担当者の好みであったり、「遅い処理はストアドプロシージャ」、などという曖昧な基準しかありませんから、システムの粒度が合わなくなるし、必ず、こんな風に

 パーツを削り出す人が出てきます。

 もちろん、システム開発というのは、何十年という間だボトムアップするために、如何にパーツを削り、如何にスマートな設計図を作るかということに注力してきたので、簡単には変わらない文化を形成しているのは分かってはいますが、パーツを削り出すならRDBMSを使う必要はないのです。

 しかも、パーツを削り出す前提でシステムをデザインするなら、システムの最後の姿は紙に描いたものしか提示できず、実物は全部が出来上がってから顧客が見るということになります。ここで、顧客との認識のズレがあると大変な手戻りをすることになります。パーツを削りだし、設計図を書いて組み立てた重厚な構造で顧客との認識のズレがあれば被害は甚大で、まさにデスマーチが鳴り響きます。

 しかし、スタブを作って先にジオラマを完成させてしまえば、顧客は先に完成した現物を見ることが可能になります。早い段階で、顧客との認識のズレを確認することができますし、顧客に確認して貰ったジオラマの部分は一切変更することなく、リリースが可能になります。

すべてのシステムに適応できるか?

 すべてのシステムに適応できるわけではありません。

 図でいうと、一つのRDBサーバで、

 の材料がすべて揃わないパターンです。しかし、業務システムの場合、当たり前のデータ量を見積もっておけば心配する必要はないでしょう。理由はこちらに書きました

 問題は無料のWEB系サービスの場合です。無料で大量のユーザを手っ取り早く獲得しようとするビジネスモデルの場合、ガンダムの上半身と下半身に分けてサーバに保存する必要があるのか、はたまた、腕と足と頭を分けて別々のサーバに保存する必要があるのか予測は困難です。しかし、そもそも業務システムと、WEB系サービスとは別物です。同じやり方をする必要は全くありませんし、同じやり方でできると考えることも馬鹿げています。別の方法を考えてください。

 私は、WEB系サービスなら、RDBMSを使う必要はほとんどないと考えているのですけれど。