ストアドプロシージャ

jQueryの勉強をしていたら、突然、ストアドプロシージャの作成を手伝ってほしいといわれた。
恥ずかしながら、私は今までストアドをまったく使ったことがなかった。だから、当然、PL/SQLT-SQLなんかも知らない。そもそも、なぜストアドが必要なのか、(分岐やループなどの)ロジックを組み込む必要のあるSQLが必要なのか、まったく理解できなかった。今まで必要なかった。だって、普通のSQLを発行して、JAVAPHPといった言語で、つまりアプリのほうでロジックを組めばいいから。よく、ストアドにすると処理速度が上がるといわれているけど、それも若干でしかないから、そちらのほうのメリットも感じなかった。
とりあえず、やれといわれているのだから、軽く説明を聞くことにした。今回はSQL Serverなので、T-SQLのほう。その説明を受けるやり取りの中でひとつ大きな発見をした。それは、今までストアドの必要がなかったのはWEBシステムだからということ。
DBからのデータの取得・加工ロジックでバグを発見した場合、どうするか。そのロジックがアプリ側で組まれていたとしよう。JAVAPHPRubyなどのソースを書き換えてバグを直すことになる。ソースを書き換えたら、必要ならコンパイルして再デプロイとなる。これでバグが直る。手順としては単純。ところが、この手順自体がWEBシステムの大きな特性なのだ。
実は、これがクラサバアーキテクチャだとこのようにはいかない。そして、社内のほとんどの案件がクラサバなのだ。そう、クラサバの場合は、「再デプロイ」という作業がサーバではなくクライアントになるので、クライアントの台数が100台なら100台、「再デプロイ」(=再インストール)しなければならない。バグを発見して直すたびにである。だから、その手間を減らすためにサーバで直せるところはサーバで直せるように実装するのだ。この方法としてストアドがある。
当然といえば当然だけど、「再デプロイ」をサーバにしかしないWEBシステム畑の人間にはその発想がなかった。
これは目からうろこが落ちるような発見であった。