tryプログラミング、リモートワーク、田舎暮らし、音楽、etc.2010-08-25ビジネスロジックをストアドに埋め込むのは避けるべきSQLストアドの中のビジネスロジックは読みにくいです。いかんせん、ベースの言語がSQLなので言語設計の時点ですでに構造化プログラミングをしようとすることに無理があります。構造化プログラミング(手続き型ロジック)の書きやすさ、読みやすさ、デバッグのしやすさはC#、Javaのような汎用的なプログラミング言語とその開発環境の方がはるかに上だと思います。COMPLETEやリファクタリングの中で挙げられているようなコーディングテクニックがほとんど使えません。その結果、ロジックの抽象化がほとんできず、複雑さがむき出しになってしまいます。結局、データベースが特に優れているのはトランザクション処理や排他制御、それと大量データの取捨選択(SELECT文)の容易さであって、それ以外のロジックは原則としてデータベースの外側で実装すべきなんじゃないでしょうか?入力データの妥当性確認等のビジネスロジックをストアドに格納すれば、実行速度やシステムを超えた再利用性が向上するというメリットもありますが、特別な事情がない限り、最初に挙げたようなデメリットを超えるほどの価値はないと思います。ストアドの優位性を強調するWeb記事や書籍を時折見かけますが、個人的にはストアドを優先的に採用する必要はないと思いますし、採用したとしても、ステートメントやブロックがいくつもあるようなロジックは埋め込むべきではないと思います。はてなブログPro株式会社ソニックガーデンで働くRubyプログラマ。2017年11月に「プロを目指す人のためのRuby入門」を出版。blog)はてなブログをはじめよう!JunichiItoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。