私のアプリケーションには、5 ~ 6 個のテーブルにまたがる複数の結合を含む単一行の選択クエリが多数あります。これらのクエリは、文字列ビルダーを使用して、フォームなどからの入力に基づく多くの条件に基づいて生成されます。しかし、たまたま sql 開発者である私のチーム リーダーは、これらの単一行のクエリをストアド プロシージャに変換するように私に依頼しました。
単一行の選択クエリをバックエンドに変換し、すべての if および else を SP として実行する利点はありますか?
すべての SQL 部分をストアド プロシージャに含める利点の 1 つは、クエリをデータベースという 1 つの場所に保持することです。そのため、アプリケーション レイヤーやフロント エンド レイヤーに多くの変更を加えることなく、変更や修正がはるかに簡単になります。
DBA または SQL の開発者は、SQL がデータベース プロシージャに格納されている場合、SQL を微調整できます。すべての関数/ストアド プロシージャをパッケージに保持できます。これは、パフォーマンスとオブジェクトの整理の点で優れています (Java でパッケージを作成するのと同様の方法)。もちろん、パッケージでは、そのオブジェクトへの直接アクセスを制限できます。
これは、チームまたは部門のポリシーであり、SQL部分をフロントエンドまたはデータベース自体に保持する場所であり、もちろん@Gimbyが述べたように、多くの人が異なる見解を持つ可能性があります。
更新 1
何かを返す select ステートメントがある場合は、関数を使用します。INSERT/UPDATE/DELETE や、電子メールの送信やその他のビジネス ルールなどの同様のものがある場合は、プロシージャを使用し、パラメータを渡してフロント エンドからこれらを呼び出します。
JavaでPreparedStatementを使用する場合、Javaクエリとストアドプロシージャのパフォーマンスに大きな違いはありません。(Javaでステートメントを使用する場合は、問題があります)。
ただし、ストアドプロシージャは、SQLコードを整理して再利用するための優れた方法です。それらをパッケージにグループ化したり、Javaコンパイルなしで変更したり、DBAまたはSQLスペシャリストが調整したりできます。
申し訳ありませんが、これは、さまざまな個人的意見に基づいてさまざまな回答が得られる質問です。
いずれにせよ、あなたがここで話しているビジネスロジックは、私の意見では、アプリケーション層に属しています。しかし、私に心から反対している Oracle 開発者のクラブ全体を知っています。