オブジェクト指向言語で処理すると工数が掛かる
数回に分けて複雑なSQLををストアドプロシージャ(ファンクション)を使ってデチューンしてみました。
整理すると
■1.OLAP関数を使って一括処理するパターン
■2.誤差配賦額をファンクションを使って計算するパターン
■3.誤差配賦額をファンクション内でループして計算するパターン
■4.ワークテーブル(ループ)を用いてストアドプロシージャ内で計算するパターン
■5.GROUP BYを使わない完全にループで計算するパターン(未実装)
5.は余りに馬鹿らしく誰のためにもならないと判断して作りませんでした。
全部で6時間ぐらい掛かりましたが、テストデータベースとデータ作成に一番時間が掛かりました。作るだけなら1.〜4.まで2倍ぐらいの差しかない。工数はコーディング量にほぼ比例している。しかし、2.〜4.のパターンだとしたら、それなりの仕様書が必要になるでしょう。これが更に工数を数倍にしてしまう原因になる。
何度も書いているようにストアドプロシージャでスタブを作っていたとすると、1.〜5.まで試行錯誤したとしても、ユーザインターフェース側は全く影響を受けません。
しかし、ストアドプロシージャを使わなかったら、オブジェクト指向言語でファンクションをメソッドにしたり、ストアドプロシージャ、ファンクション内の分岐や繰り返し部分を作ることになります。1.〜5.までを試行錯誤したとすると、データベースとのインターフェース(SQL)は都度変わりますから、更に仕様書の量が増えますし、その仕様書の段階で試行錯誤することになるかも知れません。試行錯誤するとき、オブジェクト指向言語側、データベース側の両方が同時に変わるので、設計も、実装も、同じ人が担当することが多くなるでしょう。
個人的な実感としては、3.〜5.のパターンでオブジェクト指向言語でやることが多いんじゃないかと思うが、3.〜5.のパターンを選ぶ人はSQLが十分にできるとは言い難い。
そんな状態のプロジェクトは、SQLが苦手な人が、SQL文がない状態で、SQL文を想像して仕様書を書いている。結果、実装してみて、パフォーマンスが悪かったり、SQLでできなかったりしたら、大幅なやり直し(仕様書から書き直し)ということになります。スキル差が大きいSQLの部分が分業化できない為に、同じプロジェクトでも1.〜5.まで混在することになったりもする。
オブジェクト指向言語で処理しても、できない人に合わせるということ以外にメリットは全くないのです。
ストアドプロシージャにできないのは技術者のスキルが足りない。工数・パフォーマンスを技術者のスキルとトレードオフするという、プロとしてはあってはならないことが現実的に続いている。
しかし、冷静に考えて、ストアドプロシージャを使ったスタブにしておけば、1.〜5.まで試行錯誤したとしても被害は少ない。5.のパターンになったとしても、オブジェクト指向言語でやるよりは工数は掛からないしパフォーマンスも出ます。
ストアドプロシージャにしておけば、データベース内にある情報は如何様にも処理できるのですから、最終的にできないということはあり得ない。オブジェクト指向言語で5.のパターンでできるなら、多少書きにくいけれど、必ず、ストアドプロシージャでも書けるのです。
書きにくさというのは慣れでなんとでもなるし、使う人が増えれば開発環境も良くなるでしょう。
まずは、ストアドプロシージャでスタブを作ること。ユーザインターフェースから実装し、実装後にデータベースを確定すること。
これができれば、あとは各社でオリジナルのルールを作っていけばいい。アジャイルに移行することも可能になるし、ウォータフォールを続けても、ユーザインターフェースから作れば手戻りを最小限に抑えることができます。
結果的に工数を下げることができ、今より短納期に対応できるようになります。