業務ロジックはストアド（PL/SQL）で
現状
3年ほど前から某企業の社内ＳＥとして働いてます。職場の主な仕事の内容は、システム開発（外注・内作半々）、既存システムの運用保守が主になります。一般的に顧客企業の社内ＳＥっていうのはそう入れ替わりは発生しないでしょうが、オフコン時代からシステム保守してる人もいたりもします。(業務スキルが高いので重宝されます。)
抱えてる問題・課題
世間水準(?)の技術がない
C/S時代のオラクル化で完全にベンダロックインです。C/SはOracle Forms、WebについてはOracle Application Serverのmod_plsqlをメインに使用してます。要はPL/SQL＋αでオールＯＫな世界です。
対策
「世間水準(?)の技術がない」の対策
まず、世間水準(?)の技術を必要と思う一番の理由は、互換性の問題です。Oracle Formsのようなマイナー（なんですかね？C/S時代、SIerで仕事してた時こればっかだったけど）な製品を使用してるとOSやＤＢのバージョンアップで互換性が問題になり動かなくなる確率が高いです。（サポートの問題）現在この問題に直面していて、うん千本あるプログラムをForms Web版に変換する作業（Oracle Application Server専用で動作するサービスでFormsをjava appletに変換する作業）を地道に行ってますが、検証作業にもそれなりのコストが見込まれています。本来的にはJavaや.NET化できれば理想ですが、現時点ではコスト、品質的に非現実的なので回避措置的な位置づけでコンバージョン作業をしています。
次に新規もののシステムを入れる時、何の言語を使用するかという問題があります。現在のＬＬブームをみると悩みどころですが、企業系なので無難に考えれば、Javaや.NETということで、対策の一環として内作でいくつかのシステムに適用し始めています。Javaの場合はFrameworkの選定に頭を悩ませますが、Seasar2のTeedaを採用してます。
他の対策として、私ともう１人が教え役でWEBアプリ開発の勉強会をしていく予定です。
「システムの肥大化と連携」の対策
システムの肥大化、連携については、基本的に社内ＳＥで対策をたて対応してく必要があります。対策としては、システム間で重複する機能（環境変数読み込み、シングルサインオン、メール送信機能、ファイルアップロード機能など）の外だし汎用化を進めることで、標準化、肥大化の防止と保守性の向上を見込んでいます。連携については、特にシステムの中核である業務ロジックの連携は、PL/SQL（ストアド）で実装するのが最良の選択と考えています。PL/SQL（ストアド）ならWEBサービスなど作るまでもなく容易に連携できます。
某巨大掲示板でも言われてるようにPL/SQLは
- 習得が容易
- できる事が少ないのでバージョンアップ時の互換性が高い
- ＤＢ操作が得意
なので、運用保守がメインで新技術を覚えたがらない社内ＳＥでも容易に保守できますし、DBを中心とした業務ロジックが中核をなす企業システムおいてPL/SQLのＤＢ操作のアドバンテージは非常に大きいです。また、派生効果としてWEB層のJavaや.NETがＵＩ中心のロジックとなり、こちらの保守の敷居も下がります。
PL/SQLだと先に言ったベンダロックインにはなりますが、要はその動作環境が磐石ならそれでいいかと。90年代、SIerとしてC/Sシステム中心にやってたころ、ＤＢといえばほとんどオラクルで、某大手企業などではかなりの数のオラクルのインスタンスが立ち上がってたのを記憶してます。webな時代になりオラクル以外のＤＢも普及したけど、そういった企業にはあまり影響はないのではないでしょうか。コストをかけてまで別のＤＢに変えたり、いたずらに他のＤＢを導入する必要はないので。
こちらhttp://q.hatena.ne.jp/1162199668で、WEBシステムの業務ロジックをストアド化するか議論がありましたが、結局のところシステムもオーダーメイドな商品である以上、使う側（運用・保守する側）が快適・安心で扱えることを前提に考える必要があると思います。
