日本のホワイトカラーの生産性を上げるには２
日本のホワイトカラーの生産性を上げるには、データベース設計をプログラミングの後に行うべき、そのためにはビジネスロジックをストアドプロシージャに入れる必要がある。ということを前回書きました。
今回は、具体的にどうしてストアドプロシージャが効率が良いかということを書きたいと思います。
オブジェクト指向言語に限りませんが、一般的な開発は以下の図1の様になります。
図2 ストアドプロシージャでの開発
オブジェクト指向言語で処理する場合、図1の「４．」の繰り返しが多ければ多いほどパフォーマンスが悪くなります。
ですから、よくパフォーマンスが悪ければ「４．」繰り返しを減らすように図1の「１．３．４．」の処理を修正すればよい、つまり、パフォーマンスが悪いときSQLで処理する部分を増やす。という主張を耳にすることがありますが、それは「SQLで開発した方が開発工数が著しく掛かる」という前提がある場合は正しいです。しかし、図1・2をよく見れば分かりますが、図1の「４．」繰り返しを1回にすれば図2との違いは「SQLがどこに保存されているか」しかなく、パフォーマンスも工数も大差はありません。
つまり、SQLもオブジェクト指向言語も両方とも十分に熟達している技術者が行えば、SQLで処理した方が記述やマッピングが減る分、工数は少なくなります。ここに違和感を覚える方から何度も反論を頂きましたが、それは「SQLができない人の理論」でしかないでしょう。ちなみに弊社では、中小企業の基幹システムを構築して図1の「４．」の繰り返しが必要だった機能は、約400本のプログラム中5本しかありませんでした。
さて、データベース設計より先にプログラミングするには、データベースの部分にスタブを作る必要がありますが、オブジェクト指向言語で処理している場合、次の図3のように、
図4 ストアドプロシージャでスタブ開発
非常にスッキリと分かりやすくなりますし、ストアドプロシージャのスタブはパラメータと戻り値の形が確定すればよいのですから、エクセルなどでジェネレートすることも簡単にできます。その後の、開発本番でも変更箇所が僅かですみます。
さて、オブジェクト指向言語とRDBMS（SQL）は、成り立ちからアーキテクチャーまで全く違いますから、一体のシステムにするのは非常に難しい。インピーダンスミスマッチと呼ばれるモデルの変換に関する問題があるのです。
それを一般的には、図1のようにすることで乗り越えてきました。そして、必ず起こるデータベース構造の変更とパフォーマンスチューニングのために図1の「１．３．４．」の部分を修正するのが当たり前でした。「１．」はSQLで、「３．４．」の部分はオブジェクト指向言語です。SQLは非常にスキル差が大きな技術なのにもかかわらず、このような構造では分業体制にもできませんし、プログラミングコードとしても言語がスパゲティの様に絡み合ってしまって切れません。
ストアドプロシージャを使う場合、SQLを保存しラップするだけという使い方でも、プロシージアルにループして処理する形になったとしても、オブジェクト指向言語でループすることに比べたら随分とパフォーマンスは出しやすいです。何より、オブジェクト指向言語を担当する技術者と、SQLを担当する技術者を分けることができますし、担当する会社を分けることも可能になるでしょう。どちらか一方をユーザに依頼することも可能になるかも知れません。
問題点は、データベースを別のベンダーに乗り換えるのが難しくなる。スケールアウトが難しい。という2点だけです。
実際の問題点は「嫌がる技術者が多い」「SQLのスキルが低い技術者が多すぎる」単純にこれだけの問題です。しかし、それは技術者の都合でしかないです。そんなできない技術者の都合をいつまでも許してはいけないでしょう。
SQLは好き嫌いがものすごく激しいのですから、分業を進めお互いの技術を尊重できるようにするためにも、是非、ストアドプロシージャを使ってユーザインターフェースのコーディングの後にデータベース設計を行ってみてください。びっくりするぐらい後戻りを抑えることができるようになります。
次回は、ストアドプロシージャの具体的な書き方について。
