私が携わるプロジェクトでは、
極力SQLでビジネスロジックを書くことを回避してもらってます。
理由は、SQLでロジック書かれると、
JavaとSQLでロジックが分散してしまうからです*1。
SQLだろうが、Javaだろうが、
訳のわからないロジックを書けてしまう事は事実です。
システムの目的はぶっちゃけると、
永続化してデータを貯め、それを参照させること。
システムは生き物です。今のロジックでは問題ないかもしれませんが、
遠くない未来では仕様を満たさなくなるかもしれません。
仕様が変更されると、今まで正しかった振る舞いも
正しくないことになります。
システムとして存在し続ける為に、
正しい振る舞いになるようにロジックを変更する必要があるのですが、
テスト、もしくは動作確認をする際、SQLでビジネスロジックが記述されていると
事前データの準備が必要になってきます。
テスティングフレームワークを使用すれば
その面倒さもいくらか和らぎますが
テストパターンを増やす為にテーブルのレコードを
準備しなければなりません。
そのテーブルに外部キーが張られていたら、
関連するレコードも用意しなければなりません。
テストをする為の準備に、余計な時間がかかるわけです。
また、DBで記述されたビジネスロジック部分のテストクラスを他の人が理解しようとしたら、
ビジネスロジックだけでなく、
そのテストで使用するテーブルとレコードも意識しなければなりません。
もし、DBを使用せずに引数だけで完結するようなロジックになれば
テストクラスだけ見てれば理解できるわけです。
テストするのに前提条件が多ければ、手離れの良くないテストクラスの出来上がりです。
また、SQLにロジックを書く理由として、
「SQLだけで完結すれば、呼び出し元には何も影響無いから」
ということも聞きますが、
別にJavaで書いてもインターフェースが変わらなければ
同じことでしょう。
テストのしやすさ、早めの動作確認を意識するなら、
私はSQLでロジックを書くべきじゃないと思うのです。
そして、できるだけDBアクセスする箇所はシンプルな処理が良い。
シンプルであれば、作り直すことも簡単です。
テーブル定義の変更にだって容易に対応できるでしょう。
難しいSQLを書いて、実行計画とにらめっこする必要もなくなると思います。
結合条件だって見落としに気づくレベルだと思います*2。
あんまりDBサーバに負荷かけさせないようにした方が最近のシステム構成上うまく行く気がするんだけどなー。
APサーバのCPUとメモリ使ってロジック回したほうが負荷分散にも繋がると思うのですが・・・。
運用し続けているシステムは、いつの日か、
仕様上の前提条件が覆されるときがきます。きっときます。
それは悲しいことではなく、そのシステムが使われているということの証明です。
必要とされていることの証なのです。
一度作ってしまった後に何も仕様変更が起きない、改修されないシステムは、
要件定義が完璧だった訳ではなく
十中八九使われていないと思ってよいかもしれません。
できるだけシステムはシンプルに。
変更に対して柔軟に対応できるようにしておくべきです。
変更されるケースとパターンを見越して準備してたとしても
その想定から外れることもあるでしょう*3。
ちょっとくらいダサくても、誰にとってもわかりやすいほうがいいじゃない。
