- ハンディターミナル(以下HT)、レジ、PCなど複数のクライアントに対してサービスを提供する必要があった

- HTはブリッジ(C#)を介して、レジ(C#+ローカルのオフライン用DB)は直接にRDBMSと接続するという要件があった

- 一方、PHP5で実装されたPC用クライアントはウェブアプリで、これらはほぼ、コードジェネレータで製造した

- 他に帳票やバーコードを印刷するための周辺アプリケーションを作る必要があった

- 必要工数に対して人的リソースが少なく、自分以外に期待できるものがなかった

結果として得た自分なりの結論。

- 残念ながらストアドはやっぱりテスト・デバッグ効率が悪い

- 結局のところ、ストレージエンジンとビジネスロジックとその他アプリケーション(これ自身が2階層)の3+1階層に分離しないと十分なテスト・デバッグを経た製品は難しい

若干の考察を。

- 複数種類のクライアント形態のあるシステムにおいて適切にビジネスロジックを共通化することは重要な課題である

- しかし、十分なテスト・デバッグが必要であるところのビジネスロジックをストアドで実装してしまうとテストのコストが上がり、結果として十分なテストが行えない

- パフォーマンスを求める場合にストアドで実装した方がいいという意見に対して: リアルタイムにヘビートランザクションを走らせないといけないようなアーキテクチャはそもそも破綻しているし、リアルタイムでなくてよいなら、前時代の香りはするけれど、バッチ処理なりを行えばよい。それこそOLAPなどSQLの出番ではない。

と、好きなことを書いてみました。

言ってることは納得いかんけど気持ちはわからなくはないのよね＞元記事
要するに、みんなもっとSQLをリスペクトしようぜ！ってことだけなんだろう。

まあ言いたいことはわかります。ただ、それは「SQL」というくくりよりもさらに狭いお話なんですよね。
彼の想定するようなケースなら、もっとSQLを使ったほうがいい、それも否定しない。

まあ、SQLがもっとリスペクトに値するような言語だったら何の問題も無いわけです（ひど

オイラが唯一元記事側の立場で言い切れることは、これだけだな
「モジュールのリビルドなしでイロイロとSQLだけ修正して動かせるならその方がいい
ソフトなんて作れば作っただけバグが増えて、修正した分だけ被害が広がるからね」