SQLer 生島勘富 のブログ

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

オブジェクト指向言語ならNoSQLで、RDBMSを使うならサービス指向アーキテクチャで

システム設計

図1 オブジェクト指向言語での一般的な処理

　この図は、オブジェクト指向言語としていますが、構造としてはCOBOL技術者がオープンの世界に流れてきて確立した文化からなんの変化もない。非常にいびつで、SQLとオブジェクト指向言語の言語のスパゲッティプログラムです。いびつなことはみんな分かっていて、「インピーダンスミスマッチが……」と言い出すわけです。

　オブジェクト指向言語が目指すところは下の図2のようになるでしょう。

図2 オブジェクト指向言語での理想的な処理

　この形が可能なら「なぜRDBMSを使う意味があるのか？」という疑問がふつふつと沸いてくる。この構成で可能であるならばRDBMSを使うことのメリットは「一貫性の維持」というところしかないのですが、（これは経験則で目一杯偏見を含んでいますが）図2の構成を選ぶ人が一貫性を維持するためのトランザクション処理を理解し、考慮して構築しているとは思えない。ですから、図2にするならばRDBMSにするメリットはゼロと言えるでしょう。

　何度か書いてきたけれど、図2の構成で結果を出しているのであれば、RDBMSは極めて単純な処理しかしておらず繰り返されるオーバーヘッドが非常に無駄です。RDBMSを使うべきではないところでRDBMSを使っているわけで、NoSQLに移行した方が良いでしょう。

　図2の構成を目指しても、業務システムでは、個別に「SQLという異物を書かずにすむ」ということはほとんどない。SQLという異物が混入した時点で、言語のスパゲッティの図1の構造に戻ってしまう。

　図1の構造は、COBOL技術者が考えたのと同じで、とにかく中途半端です。

　弊社であれば、図1の形になったとしても、「４．」の繰り返しが入るのは1％ぐらいですが、図1の構造では、ユーザインターフェースの設計をしながら、どの程度SQLで処理し、どの程度オブジェクト指向言語で処理するか、考えながら設計しています。そのため、担当する技術者は、SQLも分からないといけないし、オブジェクト指向言語も分からないといけません。

　結果として、スキル差の大きいSQLは、担当者によって非常に判断がバラつくので「できない人に合わせた規約」を作らざるを得ないのです。

　　　　　EXISTSは読みにくいのでINで書き直すように
　　　　　ヒントは禁止
　　　　　サブクエリは禁止
　　　　　JOIN が申請すること
　　　　　ストアドプロシージャは禁止
　　　　　OLAP関数は禁止

というような規約のあるプロジェクトが実際に多く存在します。このような禁止事項がつくと「４．」の繰り返しが10〜50％の割合で発生してしまいます。

　この禁止事項は、顧客のための規約ではなく「できない技術者に合わす」ための規約ですから、できる人にとっては、規約に合わせるために余分な工数が掛かることになります。「オブジェクト指向言語で全部staticで宣言」と全く変わらない馬鹿げた規約なわけです。

　馬鹿げた規約というのは、そもそも理屈に合わない非効率な規約ですから、運用が始まって実際にデータを入れると、パフォーマンスの要件が満たせないということも発生します。

　そのときは、規約を曲げて作り替えることになるのですが、作り直しの方が遙かに工数が少なくて済む。つまりは最初からSQLで書いていれば少ない工数でパフォーマンスも出せたのです。

図3 ストアドプロシージャを用いた処理

　ストアドプロシージャを使ってSQL（RDBMS）を疎結合にすれば、非常に綺麗な構造になります。

　SQLを使って処理する範囲は、「RDBMS内のデータとパラメータで処理できる範囲」となり、どの程度SQLで処理するかも、最終的にどんなテーブル構造になるかも考える必要はありません。

　オブジェクト指向言語ではないけれど、RDBMSをオブジェクトと考えれば「オブジェクト指向」の考え方に合致しますし、データの永続性に関するサービスを提供すると考えれば、「サービス指向アーキテクチャ（SOA）」とも言えます。（WEBサービスだけがSOAではありません）

　SOAでは「どんなサービスを提供できるか」というサービス提供側の都合で構築するのはよくないでしょう。図3であれば、ユーザインタフェース側の担当者が、「こんなサービスが欲しい」というリクエストを出し、そのリクエストに応える形でサービスを構築するのが効率的です。

　と考えると、エクセルでパラメータと戻り値をジェネレートすることで、「こんなサービスが欲しい」というリクエストを簡単に伝えることができます。

　ユーザインタフェース側の担当者は、自分に最も都合がよい形の戻り値をリクエストすればよく（命名規則と型の決め事は必要ですけれど）、自分に最も都合が良い形の戻り値が得られるとすれば、IDEやフレームワーク、O/Rマッパのマッピング機能などを最大限に活かすことができます。

　ビジネスロジックを抜いてユーザインターフェースに特化すれば、最近のフレームワークの出来から考えると、8割ぐらいはマウス操作のみでコーディングが終わるでしょう。

　開発の初期からユーザに動くものを見せることができますし、ぶっちゃけて、システム部がある会社ならユーザ自身が作った方が良いものができるはずです。

　それなりの大手で早く移行できれば過渡期は儲かるし、日本のホワイトカラーの生産性は先進国で最低ランクというのは、我々IT技術者が世界最低ランクという意味です。最高ランクになるまで、まだまだ、仕事は作っていけるはずです。

　オブジェクト指向言語のこだわりなんて、本当に小さな小さな事柄だと私は思う。そんな小さな事柄をガタガタ言うのではなく、まずは、「できない理論」を恥ずかしげもなくいう連中を駆逐することで、業界を変えたい。