ビジネスロジックをストアドに埋め込むのは避けるべき

ストアドの中のビジネスロジックは読みにくいです。

いかんせん、ベースの言語がSQLなので言語設計の時点ですでに構造化プログラミングをしようとすることに無理があります。
構造化プログラミング(手続き型ロジック)の書きやすさ、読みやすさ、デバッグのしやすさはC#、Javaのような汎用的なプログラミング言語とその開発環境の方がはるかに上だと思います。

そもそもT-SQLやPL/SQLでは、CODE COMPLETEやリファクタリングの中で挙げられているようなコーディングテクニックがほとんど使えません。
その結果、ロジックの抽象化がほとんできず、複雑さがむき出しになってしまいます。

結局、データベースが特に優れているのはトランザクション処理や排他制御、それと大量データの取捨選択(SELECT文)の容易さであって、それ以外のロジックは原則としてデータベースの外側で実装すべきなんじゃないでしょうか？

入力データの妥当性確認等のビジネスロジックをストアドに格納すれば、実行速度やシステムを超えた再利用性が向上するというメリットもありますが、特別な事情がない限り、最初に挙げたようなデメリットを超えるほどの価値はないと思います。

ストアドの優位性を強調するWeb記事や書籍を時折見かけますが、個人的にはストアドを優先的に採用する必要はないと思いますし、採用したとしても、ステートメントやブロックがいくつもあるようなロジックは埋め込むべきではないと思います。

CODE COMPLETE 第2版 上 完全なプログラミングを目指して

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)