私は世界のトップ3のITコンサルティング会社の1つのプロジェクトで働いており、DBAから、会社のベストプラクティスのステートストアドプロシージャは「ベストプラクティス」ではないと言われました。これは私が学んだことすべてに反している。

ストアドプロシージャにより、コードの再利用、カプセル化（ソフトウェア開発の2つの柱）、セキュリティ（個々のストアドプロシージャに対するアクセス許可の付与/取り消しが可能）、SQLインジェクション攻撃からの保護、スピードの向上（DBAによるとSQL Server 2008以降では、通常のSQLクエリでも十分な回数実行されるとコンパイルされます）。

アジャイルソフトウェア開発方法論を使用して複雑なアプリを開発しています。誰もがストアドプロシージャを使用したくない理由を考えることができますか？私の推測では、DBAはこれらのストアドプロシージャを維持することを望んでいませんでしたが、そのような設計上の決定を正当化するには、あまりにも多くのネガが存在するようです。

私の非常に大規模なプロジェクトでの経験では、ビジネスロジックがどこにあるのかを明確にする必要があります。個々の開発者がビジネスロジックをビジネスオブジェクト層またはストアドプロシージャに適切に配置できる環境を許可すると、大規模なアプリケーションの理解と保守が非常に難しくなります。

ストアドプロシージャは、特定のDB操作を高速化するのに最適です。私のアーキテクチャ上の決定は、すべてのロジックをアプリケーションのビジネスレイヤーに残し、ストアドプロシージャをターゲットを絞った方法で採用して、ベンチマークで正当であることが示されている場合にパフォーマンスを改善することです。

いくつかの観察

ストアドプロシージャは、コードの再利用とカプセル化（ソフトウェア開発の2つの柱）を提供します。

それらが使用されることになっているコンテキストでそれらを正しく使用する場合のみ。関数（構造化プログラミング）またはメソッド（オブジェクト指向プログラミング）についても同じ主張が言えますが、1K関数と巨大なオブジェクトがあります。

アーティファクトはあなたにそれらの利点を与えません。これらのアーティファクトを適切に使用することが、これらのメリットをもたらします。

セキュリティ（個々のストアドプロシージャに対する権限を付与/取り消しできます）、

はい。これは良い点であり、ストアドプロシージャが好きな主な理由の1つです。これらは、ビューとユーザーアカウントだけで通常達成できるものよりもきめ細かなアクセス制御を提供します。

SQLインジェクション攻撃から保護します。

パラメーター化されたSQLステートメントと入力スクラブで同じレベルの保護を実現できるため、これはSPに固有のものではありません。ただし、「セキュリティの詳細」の問題として、SPに加えてSPを使用します。

また、速度の向上にも役立ちます（ただし、DBAは、SQL Server 2008以降、通常のSQLクエリでも十分な回数実行されるとコンパイルされると述べています）。

これはデータベースベンダー固有のものですが、一般的にDBAは正しいです。SQLステートメント（静的またはパラメーター化されたもの）はコンパイルされます。SPは、単純なSQLステートメントでは実行できないデータを集計および計算する必要がある場合に役立ちますが、SQLと緊密に統合されており、アプリサーバーへのラウンドトリップを保証しません。

良い例は、別のSQL自体を実行するための一時的なカーソルにデータをクエリすることです。アプリサーバーでプログラムで実行することも、dbで実行することで複数のラウンドトリップを保存することもできます。

ただし、これは標準ではありません。これらのケースが多数ある場合、それは悪いデータベース設計の兆候です（または、部門間であまり互換性のないデータベーススキーマからデータを引き出しています）。

アジャイルソフトウェア開発方法論を使用して複雑なアプリを開発しています。

敏ility性は、テクノロジーではなく、ソフトウェアエンジニアリングプロセスと要件管理に関係しています。

誰もがストアドプロシージャを使用したくない理由を考えることができますか？

間違った質問

質問は間違っており、「GOTOを使用しない正当な理由はありますか？」このテーマに関しては、ダイクストラよりもニクラウス・ワースの側にいます。ダイクストラの感情はどこから来たのかは理解できますが、すべての場合に100％適用できるとは思いません。ストアプロシージャおよびその他のテクノロジでも同じです。

ツールは、意図した目的に適切に使用され、特定のタスクに最適なツールである場合に適しています。それ以外の方法で使用することは、ツールが間違っていることを示すものではありませんが、使用者は自分が何をしているかを知りません。

適切な質問は、「どのような種類のストアドプロシージャの使用パターンを避ける必要があるか」です。または、「条件はI（またはすべきでない）ストアドプロシージャを使用すべきか下」。テクノロジーを使用しない理由を探すのは、エンジニアの責任をエンジニアリングの責任に直接置くのではなく、単にツールに責任を負わせることです。

言い換えれば、それは警戒または無知の声明です。

私の推測では、DBAはこれらのストアドプロシージャを維持することを望んでいませんでしたが、そのような設計上の決定を正当化するには、あまりにも多くのネガが存在するようです。

そのとき彼らがしていることは、彼らの悪いエンジニアリング決定の結果を彼らが不十分に使用したツールに投影することです。

あなたの場合はどうしますか？

私の経験は、ローマにいるとき、ローマ人と同じようにしています。

戦わないでください。あなたの会社の人々がストアprocを悪い慣習として分類したいなら、彼らに任せましょう。ただし、これはエンジニアリングプラクティスの危険を招く可能性があることに注意してください。

悪い慣習としての物事の典型的なラベル付けは、通常、無能なプログラマーがたくさんいる組織で行われます。特定のものをブラックリストに登録することにより、組織は自分の無能によって内部的に与えられる損害を制限しようとします。クソじゃない

一般化は、すべてのねじ込みの母です。ストアドプロシージャ（または任意の種類のテクノロジ）は悪い習慣であると言って、それは一般化です。一般化は、無能な人のための警戒です。エンジニアはあからさまな一般化を行いません。彼らは、問題を解決することになっている状況で、ケースバイケースで分析を行い、分析のトレードオフを行い、手元の事実に応じてエンジニアリングの決定とソリューションを実行します。

優れたエンジニアは、このような一般化された方法で物事を悪い慣行として分類しません。彼らは問題を見て、適切なツールを選択し、トレードオフを行います。言い換えれば、彼らはエンジニアリングを行います。

それらを使用しない方法に関する私の意見

• データ収集（およびおそらくいくつかの変換）以外の複雑なロジックを配置しないでください。それらにいくつかのデータマッサージロジックを配置したり、複数のクエリの結果を集約したりすることは問題ありません。しかし、それはそれについてです。それを超えるものは、ビジネスロジックとして適格であり、他の場所に存在する必要があります。

• SQLインジェクションに対する唯一の防御メカニズムとしてそれらを使用しないでください。何か悪いことが起こった場合に備えてそこに残しますが、それらの前には多数の防御ロジックが必要です-クライアント側の検証/スクラビング、サーバー側の検証/スクラビング、おそらくあなたの中で意味のある型への変換ドメインモデル、最後にパラメータ化されたステートメント（パラメータ化されたSQLステートメントまたはパラメータ化されたストアドプロシージャ）に渡されます。

• データベースを、ストアプロシージャを含む唯一の場所にしないでください。ストアプロシージャは、C＃またはJavaソースコードを処理するのと同じように処理する必要があります。つまり、ソースはストアプロシージャのテキスト定義を制御します。人々は、ストアプロシージャをソースコントロールできないことをります-強気、彼らは単に彼らが話している血まみれの地獄を知りません。

それらをどのように/どこで使用するかについての私の意見

• アプリケーションには、複数のクエリまたはビューから転置または集計する必要があるデータが必要です。これをアプリケーションからデータベースにオフロードできます。ここでは、a）データベースエンジンはこれらのことを行うアプリサーバーよりも効率的ですが、 b）アプリサーバーは（場合によっては）水平方向に拡張しやすいため、パフォーマンス分析を行う必要があります。

• きめ細かいアクセス制御。データベースでデカルト結合を実行するバカは必要ありませんが、同様に任意のSQLステートメントを実行することを禁止することはできません。典型的なソリューションは、開発環境とUAT環境で任意のSQLステートメントを許可し、systestおよび実稼働環境ではそれらを禁止することです。systestまたはプロダクションに到達する必要があるステートメントは、開発者とdbasの両方によってコードレビューされたストアプロシージャに入ります。

ストアプロシージャにない SQLステートメントを実行する有効な必要性は、異なるユーザー名/アカウントと接続プールを使用します（使用状況は厳しく監視され、推奨されません）。

• Oracleのようなシステムでは、LDAPへのアクセスを得ることができ、または外部データベースへのシンボリックリンクを作成します（VPN経由でのビジネスパートナーのDBに格納PROCを呼び出すと言う。）スパゲッティコードを実行する簡単な方法を、それは、すべてのプログラミングパラダイムのために本当の、そして時には特定のビジネス/環境要件があり、これが唯一のソリューションです。ストアプロシージャは、アプリサーバーに移動することなく、データに近い1か所だけでその厄介さをカプセル化するのに役立ちます。

これをストアプロシージャとしてdbで実行するか、アプリサーバーで実行するかは、エンジニアとして行う必要があるトレードオフ分析に依存します。両方のオプションを分析し、何らかの分析で正当化する必要があります。単に他の選択肢を「悪い習慣」として非難することによって、何らかの形で進んでいくことは、単なる不十分なエンジニアリングのコップアウトです。

• アプリサーバーを単純にスケールアップできない状況（つまり、新しいハードウェアまたはクラウドインスタンスの予算がない）で、dbバックエンドに十分な容量がある場合（これは多くの人が認めたいと思うより一般的です） procを保存するためにビジネスロジックを移動します。きれいではなく、貧弱なドメインモデルにつながる可能性があります...しかし、それでも...トレードオフ分析、ほとんどのソフトウェアハックが吸い込むもの。

それが永続的な解決策になるかどうかにかかわらず、それはその特定の瞬間に観察される制約に固有のものです。

それが役に立てば幸い。

その理由は、ストアドプロシージャレイヤーに依存すると移植性が制限され、特定のDBに結び付けられるからです。追加されたメンテナンス費用も理由として挙げられます。この点についてもコメントしたいと思います。

（ストアドプロシージャ）SQLインジェクション攻撃から保護する

実際には、パラメータ化されたクエリが保護されます。これは、プレーンテキストのSQLクエリで簡単に実行できます。

ストアドプロシージャに同意するいくつかの理由はベストプラクティスではありません。

• ビジネスおよびアプリケーションのロジックは、データベースではなくコード内にある必要があります。DBにロジックを配置することは懸念事項を混乱させます。
• ストアドプロシージャは、アプリケーションロジックの残りの部分で、従来の単体テストプロジェクトのコードほどシームレスにテストすることはできません。
• コードを書いているときに、最初のプログラミングをテストするのに役立つストアドプロシージャが見つかりません。
• ストアドプロシージャは、IDEでプログラムをデバッグするときに、アプリケーションコードほど簡単にデバッグできません。
• バージョン管理/ SPのソース管理と通常のコード

ストアドプロシージャは、コードの再利用とカプセル化（ソフトウェア開発の2つの柱）を提供します。

はい。ただし、他のアジャイルデザインの目標を達成できるという犠牲が伴います。1つには、保守がより困難です。私が取り組んでいるプロジェクトが何らかの兆候である場合、本質的に同じ仕事をする利益のない、互換性のない複数のSPになる可能性があります。

SQLインジェクション攻撃から保護します。

いいえそうではありません。よく言われるように、このアイデアはどこから来たのか推測することすらできません。それは単に真実ではありません。特定の種類のSQLインジェクション攻撃を軽減する可能性がありますが、最初にパラメーター化されたクエリを使用していない場合、それは重要ではありません。私はまだ '; DROP TABLE Accounts; -

また、速度の向上にも役立ちます（ただし、DBAは、SQL Server 2008以降、通常のSQLクエリでも十分な回数実行されるとコンパイルされると述べています）。

また、通常、準備済みのパラメーター化されたステートメントを使用するときにコンパイルされます（少なくとも使用したDBのいくつかで）。アプリケーションがクエリの実行を開始するまでに（または、同じ準備済みクエリを複数回実行する場合は特に）、SPが持つと思われるパフォーマンス上の利点は完全に意味がありません。

唯一のあなたは、複数の照合情報源から引っ張る複雑な、多段階のクエリを作成する必要があるときに、ストアドプロシージャを使用する理由は、私見、です。SPには低レベルの決定ロジックを含めるべきではなく、単純なクエリを単純にカプセル化するべきではありません。利点はなく、多くの欠点しかありません。

DBAを聞いてください。彼は何が起こっているか知っています。

数年前にビッグファイブの1つで働いていたとき、これは公式の行でした。理論的根拠は、SPは特定の実装（PL / SQL対T / SQL対...）に結び付けられているため、SPは不必要にテクノロジーの選択を制限するということでした。

T / SQLからPL / SQLへの1つの大規模システムの移行を経験してきたので、議論を理解できます。私はそれはちょっとしたことだと思います- 気まぐれにデータベース間で実際に移動する場所はいくつありますか？

私が勤務する3社はすべて、SQL Serverを使用したアプリケーションロジックのストアドプロシージャを使用していました。私は本当に他のものを見ていない。しかし、私にとっては大きな混乱です。通常、ストアドプロシージャを使用したエラー処理機能やコード再利用機能はあまり優れていません。

使用するデータセットを返すストアドプロシージャがあるとします。今後のストアドプロシージャでどのように使用できますか？そのためのSQL Serverのメカニズムはあまり良くありません。EXEC INTO ...ネストの1つまたは2つのレベルでのみ機能します（今は忘れています）。または、作業テーブルを事前に定義して、キーを設定して処理する必要があります。または、一時テーブルを事前に作成して、プロシージャにデータを設定する必要があります。しかし、2人が同時に使用する予定のない2つの異なる手順で一時テーブルを同じものと呼ぶとしたらどうでしょうか。通常のプログラミング言語では、関数から配列を返すか、それらの間で共有されるオブジェクト/グローバル構造を指すことができます（グローバル構造を変更するだけでなく、データ構造を返す関数型言語を除く...） ）

コードの再利用はどうですか？共通の式をUDF（またはさらに悪いサブクエリ）に入れ始めると、コードが停止します。ストアドプロシージャを呼び出して列の計算を実行することはできません（カーソルを使用し、列の値を1つずつ渡してから、何らかの方法でテーブル/データセットを更新しない限り）。したがって、基本的に最大のパフォーマンスを得るには、保守の悪夢である場所全体に共通の式をカット/ペーストする必要があります... SQL文字列。その後、数式を調整する必要がある場合は、1か所で変更を加えることができます...

エラー処理はどうですか？SQL Serverには、ストアドプロシージャの実行をすぐに停止させるエラーや、強制的に切断するエラーが数多くあります。2005年以降、try / catchがありますが、まだ捕捉できないエラーが多数あります。また、エラー処理コードのコードの複製でも同じことが起こります。例外を簡単に渡したり、ほとんどのプログラミング言語ほど簡単に例外を上位レベルに上げたりすることはできません。

また、ちょうどスピード。データセットに対する操作の多くは、SET指向ではありません。行指向のものを行おうとする場合、カーソルを使用するか、「カーソル」を使用します（開発者が各行を1つずつ照会し、内容をカーソルのように@変数に格納することがよくあります）。 ..これはしばしばFORWARD_ONLYカーソルよりも遅いですが。SQL Server 2000では、殺す前に1時間実行していたものがありました。そのコードをPerlで書き直し、20分で終了しました。Cよりも20〜80倍遅いスクリプト言語がSQLのパフォーマンスを低下させる場合、SQLで行指向の操作を記述するビジネスは絶対にありません。

現在、SQL ServerにはCLRが統合されており、CLRストアドプロシージャを使用すると、これらの問題の多くは解消されます。しかし、多くのDBAは.NETプログラムの記述方法や、セキュリティ上の問題のためにCLRをオフにしてTransact SQLに固執する方法を知りません。... 。

また、一般的にスケールアウトが最も難しいのはデータベースです。すべてのビジネスロジックがデータベースにある場合、データベースが遅くなりすぎると問題が発生します。ビジネスレイヤーがある場合は、キャッシュとビジネスサーバーを追加するだけでパフォーマンスを向上できます。従来、windows / linuxをインストールして.NET / Javaを実行する別のサーバーは、別のデータベースサーバーを購入してSQL Serverのライセンスを追加するよりもはるかに安価です。ただし、SQL Serverには現在、より多くのクラスタリングサポートがありますが、当初は実際にはサポートされていませんでした。したがって、多額の資金がある場合は、クラスタリングを追加したり、ログ配布を行って複数の読み取り専用コピーを作成したりできます。しかし、全体としてこれは、キャッシュの背後に何かを書き込むだけでなく、はるかにコストがかかります。

Transact-SQL機能もご覧ください。文字列操作？Java String Class / Tokenizer / Scanner / Regexクラスはいつでも受講します。ハッシュテーブル/リンクリスト/など。Java Collectionフレームワークなどを取り上げます。.NETでも同じです。C＃とJavaはどちらもTransact SQLよりも進化した言語です... Transact-SQLでのヘックコーディングは、Cにjeしています。 。

プラスストアドプロシージャは、大きなデータセットを操作し、複数のクエリ/基準を適用して、ビジネスレイヤーに戻す前に縮小するためにより効率的です。大量の巨大なデータセットをクライアントアプリケーションに送信し、クライアントでデータを分解する必要がある場合、サーバーですべての作業を行うよりもはるかに効率が悪くなります。

また、ストアドプロシージャはセキュリティに適しています。基になるテーブルへのすべてのアクセスを切断し、ストアドプロシージャを介したアクセスのみを許可できます。XMLのような最新の手法を使用すると、バッチ更新を行うストアドプロシージャを使用できます。その後、すべてのアクセスはストアドプロシージャを介して制御されます。これにより、アクセスが安全で正しい限り、データの整合性を高めることができます。

プログラミング言語側でクエリをパラメーター化したため、SQLインジェクション引数は実際にはあまり適用されません。また、実際には、パラメーター化されたクエリの前でも、ほとんどの場合、replace（ "'"、 "' '"）が機能していました（ただし、文字列の末尾を過ぎて目的のものを取得するためのトリックがまだあります）。

全体的に、SQLとTransact SQLは、データのクエリ/更新に最適な言語だと思います。しかし、あらゆる種類のロジックをコーディングするために、文字列操作（またはファイル操作など）を行う場合は、xp_cmdshellで何ができるかに驚くでしょう。...）いいえ。ストアドプロシージャをほとんど使用しない将来の場所を見つけたいと思っています。コードの保守性の観点から、それらは悪夢です。また、プラットフォームを切り替えたい場合はどうなりますか（実際にOracle / DB2 / Sybase / Sql Server /などにお金を払った場合、あなたが助けてくれる独自の拡張機能を使用することで、それらからすべてを引き出すこともできます。 ..）。

また、驚くべきことに、ビジネスロジックが同じではないことがよくあります。理想的な世界では、すべてのロジックをストアドプロシージャに入れて、アプリケーション間で共有します。しかし、多くの場合、ロジックはアプリケーションに基づいて異なり、ストアドプロシージャは最終的に非常に複雑なモノリスになります。一方、優れたオブジェクト指向言語を使用すると、各アプリケーションが独自のニーズに合わせてオーバーライドできる標準インターフェイス/フックを備えたデータアクセスレイヤーをコーディングできます。

サーバー上のストアドプロシージャをどのようにバージョン管理しますか？

バージョン管理からサーバーにストアドプロシージャを再展開すると、ストアド実行プランが吹き飛ばされます。

ストアドプロシージャは、サーバー上で直接変更できないようにする必要があります。そうでない場合、デプロイメントツールは、ストアドプロシージャをデータベースに書き込むためのアクセスを必要とします。ビルドごとにデプロイする必要があります（実行計画は異なる必要がある場合があります）

ストアドプロシージャは移植性がありませんが、SQLも一般的ではありません（Oracleの日付処理-uggghhhを見たことはありません）。

したがって、移植性が必要な場合は、内部データアクセスAPIを構築します。これは関数呼び出しのように呼び出すことができ、内部的にはパラメーター化されたクエリを使用して、必要な用語を組​​み込み、バージョン管理することができます。

これは私が学んだことすべてに反している。

もっと出かける必要があるかもしれません。[grin]真剣に、ストアドプロシージャは少なくとも10年間減少しています。n層がクライアントサーバーに取って代わって以来、ほぼずっと。Java、C＃、Pythonなどのオブジェクト指向言語の採用によって、衰退は加速されました。

それは、ストアドプロシージャに支持者や支持者がまだいないということではありません-しかし、これは長期にわたる議論と議論です。それは新しいものではなく、おそらくかなり長い間続いているでしょう。IMO、ストアドプロシージャの対戦相手が明らかに勝っています。

ストアドプロシージャにより、コードの再利用とカプセル化が可能になります（ソフトウェア開発の2つの柱）

本当です。しかし、適切に設計されたオブジェクト指向レイヤーも同様です。

セキュリティ（個々のストアドプロシージャのアクセス許可を付与/取り消しできます）

あなたはそれを行うことができますが、深刻な制限のためにそれを行う人はほとんどいません。DBレベルのセキュリティは、コンテキストを意識した意思決定を行うほど細かくありません。パフォーマンスと管理のオーバーヘッドのために、ユーザーごとの接続も珍しいため、アプリコードにはある程度の承認が必要です。ロールベースのログインを使用できますが、新しいロール用にそれらを作成し、実行しているロールを維持し、接続を切り替えてロギングなどの「システムレベル」の動作を行う必要があります。が所有している-DBへの接続も同様です。

SQLインジェクション攻撃からあなたを守る

パラメーター化されたクエリを実行すること以上のことはありません。とにかくあなたがしなければならないこと。

また、速度の向上にも役立ちます（ただし、DBAは、SQL Server 2008以降、通常のSQLクエリでも十分な回数実行されるとコンパイルされると述べています）。

それはMSSQL 7または2000で始まったと思います。ストアドプロシージャとインラインSQLのパフォーマンスについては、多くの議論、測定、誤報がありました。すべてYAGNIにまとめました。そして、必要な場合はテストしてください。

アジャイルソフトウェア開発方法論を使用して複雑なアプリを開発しています。誰もがストアドプロシージャを使用したくない理由を考えることができますか？

あなたが望む多くの理由は考えられません。Java / C＃/ any 3rd GL言語はすべて、カプセル化、再利用、felxibilityなどの点でT-SQLよりもはるかに優れています。そのほとんどは、まともなORMがあれば無料です。

また、「必要に応じて配布するが、それ以上ではない」というアドバイスを与えられた-最近の証拠の負担はSP支持者にあると思う。ストアドプロシージャを多用する一般的な理由は、T-SQLがオブジェクト指向よりも簡単であり、ショップにはオブジェクト指向よりも優れたT-SQL開発者がいることです。または、DBAがデータベース層で停止し、ストアドプロシージャがdevとDBAの間のインターフェイスであること。または、セミカスタム製品を出荷しており、ストアドプロシージャはユーザーがカスタマイズできます。そのようないくつかの考慮事項がなければ、最近のアジャイルSWプロジェクトのデフォルトはORMになると思います。

上記のすべてのケースを考慮して、もう1つ追加します。SPの選択は、人々の選択にも依存します。

人々が非常に複雑なロジックをSPに入れると、私は個人的に不満を感じます。そのようなSPは保守とデバッグが非常に複雑だと思います。コードビハインド（言語部分など）でのデバッグがSPよりもはるかに簡単な場合、開発者自身が問題に直面することも多くあります。

SPは、単純な操作にのみ使用してください。まあそれは私の選択です。

ストアドプロシージャに関するいくつかの問題を取り上げたいと思います。LedgerSMBでこれらを広範囲に使用しますが、ルールは、いくつかの非常に具体的な拡張を加えて、「クエリの場合、ストアドプロシージャにする」というものです。

これを行う理由は、言語間のクエリの再利用を容易にするためです。これを正直に行うより良い方法はありません。

最後に、質問は常に詳細にあります。よく使用されるストアドプロシージャを使用すると、作業が非常に簡単になります。

反対側に。

1. 従来使用されているように、ストアドプロシージャは脆弱です。単独で使用すると、呼び出し構文が変更された以外の理由で予期しない場所でコードにバグを追加する可能性が生じます。単独で使用すると、これは少し問題です。レイヤー間の凝集度が高すぎるため、問題が発生します。

2. はい、動的sqlを実行する場合、intra-sproc sqlインジェクションを使用できます。この分野に自信を持ちすぎるのは良くないことであり、その結果、この分野のセキュリティに関してかなりの経験を積む必要があります。

3. インターフェイスの変更は、上記の理由＃1のストアドプロシージャでは多少問題がありますが、多数のクライアントアプリが関係する場合、これは非常に大きな悪夢になります。

上記を否定するのはかなり難しいです。彼らは起こります。誰でも、プロSPとアンチSPはおそらくこれらに関して恐ろしい話をしているでしょう。問題は解決不可能ではありませんが、注意を払わなければ解決できません（LedgerSMBでは、サービスロケーターを使用して実行時にSP呼び出しを動的に構築し、上記の問題を完全に回避します。のみ、他のデータベースに対しても同様のことが可能です）。

ポジティブに。上記の問題を解決できると仮定すると、以下が得られます。

1. 集合演算の明快さを高める可能性。これは、クエリが非常に大きいか非常に柔軟な場合に特に当てはまります。これにより、テスト容易性も向上します。

2. この領域ですでにサービスロケーターを使用している場合、ストアドプロシージャを使用すると、アプリケーション開発者がデータベースの問題から解放され、その逆も可能になるため、開発の速度が向上します。これは正しいことをするのに多少の困難を伴いますが、それはそれほど難しくありません。

3. クエリの再利用。

ああ、SPでほとんど絶対にすべきでないこと：

1. 非トランザクションロジック。注文は発送されたが、トランザクションはロールバックされたという電子メールを送信しました...または、電子メールサーバーがオンラインになるまで続行するのを待っています...または、メールサーバー....

2. プロシージャロジックが散在する、多くの小さなクエリがゆるく結合されています。

誰のために働いているのですか？

答えは、あなたが雇用されている人、コンサルティング会社、または会社自体によって異なります。企業にとって最適なのは、多くの場合、コンサルティング会社や他のソフトウェアベンダーにとって最適ではありません。例えば、スマートな会社は、競合他社に対して永続的な優位性を持ちたいと望んでいます。対照的に、ソフトウェアベンダーは、特定の業界のすべてのビジネスに同じソリューションを低コストで提供できるようにしたいと考えています。彼らがこれで成功した場合、クライアントにとって純競争上の優位性はありません。

この特定のケースでは、アプリケーションが行き来しますが、非常に頻繁に、企業データベースは永久に存続します。RDBMSが行う主なことの1つは、迷惑データがデータベースに入らないようにすることです。これには、ストアドプロシージャが含まれる場合があります。ロジックが優れたロジックであり、毎年変更される可能性が非常に低い場合、データベースを使用するために作成されたアプリケーションに関係なく、内部に一貫性を保ち、データベースに格納しないのはなぜですか？数年後、誰かがデータベースについて尋ねたい質問を持ち、ジャンクがDBに入ることを妨げられている場合、それは答えられるでしょう。

だから、これはあなたのDBAがコンサルティング会社で働いているという事実と関係があるかもしれません。コードを移植できるほど、クライアント間でコードを再利用できるようになります。アプリでより多くのロジックを結び付けることができれば、より多くの会社がベンダーと結婚します。彼らがプロセスで大きな混乱を残した場合、彼らはそれをきれいにするために報酬を受け取るか、再び混乱を見ることはありません。いずれにせよ、彼らにとっては勝利です。

（多くの）フェンスの両側の詳細については、コーディングの恐怖での議論を読んでください。FWIW私はSPを支持する人々の側に傾いています。

データベースブランドを切り替えて、同じストアドプロシージャを使用することは非常に困難です。

あなたのチームはDBAを持っていないか、他の誰もsqlに関係したくありません。

これは、プログラマーv DBA放尿コンテストに他なりません。

IMOそれは依存します。ストアドプロシージャには場所がありますが、ベストプラクティスではありません。また、決して回避すべきものでもありません。スマートな開発者は、特定の状況を適切に評価し、ストアドプロシージャが答えであるかどうかを判断する方法を知っています。個人的には、事前定義されたレポートなどを除き、ストアドプロシージャではなく、ある種のORM（未加工のLinq to Sqlのような基本的なものでも）を使用するのが好きです。

異なるプログラミング言語を使用して、ビジネスロジックを異なるレイヤーに分割することは常に問題の原因です。ワールドを切り替える必要がある場合、バグの追跡や変更の実装は非常に困難です。

そうは言っても、すべてのビジネスロジックをデータベースに存在するPL / SQLパッケージに入れることで非常にうまくいく企業を知っています。これらは非常に大きなアプリケーションではありませんが、些細なことでもありません。20K-100K LOCと言います。（PL / SQLはT-SQLよりもこの種のシステムに適しているため、T-SQLしか知らない場合は、おそらく今は信じられないことに頭を振るでしょう...）

これはまだ言及されていない別のポイントです。

コード生成ツールとリバースエンジニアリングツールは、ストアドプロシージャにうまく対応できません。通常、ツールはprocが何をするのかわかりません。プロシージャは結果セットを返しますか？いくつかの結果セット？複数のテーブルと一時テーブルから結果セットをフェッチしますか？procは単にカプセル化された更新ステートメントであり、何も返しませんか？結果セット、戻り値、および「コンソール出力」を返しますか？

したがって、ツールを使用してデータ転送オブジェクトのDTOおよびDAOレイヤーを自動的に作成する場合（liferayの「サービスビルダー」など）、簡単に作成することはできません。

さらに、HibernateのようなORMは、データソースがSPの場合、実際に適切に動作できません。データアクセスは最高で読み取り専用です。

単独でプログラミングする場合、ストアドプロシージャを書くことに抵抗することはできません。

私は主にMySQLを使用しています。PostGreSQLのようにオブジェクト指向データベースを使用したことはありませんが、MySQLでSPを使用してできることは、テーブル構造を少し抽象化することです。SPを使用すると、その下のデータベースが変更されても、入力と出力が変更されないこれらのプリミティブアクションを設計できます。

だから、という手順がありますlogIn。ログインすると、常にを通過usernameしpasswordます。返される結果は整数userIdです。

場合はlogIn、ストアドプロシージャで、今私は、最初のログのように同時に起こるログイン時に行われるための追加作業を追加することができます。私は、ストアドプロシージャに埋め込まれたロジックとSQLステートメントのシリーズを見つける書くことが容易に（呼び出しより環境FETCH）->（結果の取得）->（環境FETCHの呼び出し）ロジックサーバー側を記述するときに行う必要があるシリーズ。

また、ストアドプロシージャがサーバーのCPU時間を使用することを指摘しておきます。たくさんではなく、いくつか。作業手順で実行される作業の一部は、アプリで実行できます。アプリレイヤーのスケーリングは、データレイヤーよりも簡単です。

私は、かなり長い間、コミュニティが本当にストアドプロシージャから遠ざかっていることをマークに同意します。元のポスターが私たちがSPを使用したい理由を挙げた点の多くは一時的に有効でしたが、それはかなりの時間であり、別のポスターが言ったように、環境は変わりました。たとえば、SPを「1日で」使用するための1つの引数FORは、実行プランが「プリコンパイル」され、コードからの動的SQLは実行ごとに「再コンパイル」する必要があるため、パフォーマンスが向上したことを覚えています。主要なデータベースが変更、改善、適応などされたため、これはもはや当てはまりません。

とはいえ、現在のプロジェクトではSPを使用しています。その理由は、単にレガシーアプリケーションをサポートしている既存のデータベースの上に新しいアプリケーションを構築しているからです。その結果、レガシーアプリをオフにするまで、スキーマを変更することは非常に困難です。アプリケーションに必要な動作とルールに基づいて新しいアプリケーションを設計し、SPを使用して一時的にデータベースとやり取りし、既存のSQLにSPを適応させることを意識的に決定しました。 。これは、SPを使用すると、アプリケーションコードの変更を必要とせずにデータベースレベルでの変更が容易になるという以前の投稿者のポイントに行き着きます。アダプタパターンの実装としてSPを使用することは確かに理にかなっています（特に現在のプロジェクトを考えると）。

ちなみに、スキーマが更新されたらSPを削除するつもりです。しかし、企業開発における他のすべてと同様に、それが起こるかどうかを確認します！[にやにや]

ストアドプロシージャの使用をお勧めする方法の簡潔な概要を作成したかっただけです。私はそれらが悪い習慣であるとはまったく思いませんし、他の人が言ったように彼らは適切な状況で使用されるべきです。

さまざまなアプリケーションの手順を記述すると機能が混乱し、アプリケーションのビジネスロジックが分離され、データベースがより乱雑で制限的なものになるという問題を見ることができます。

したがって、データベースに固有のリレーショナルデータ指向タスクでストアドプロシージャを使用します。つまり、データベース操作に使用されるロジックがアプリケーションのデータと一貫している場合、ストアドプロシージャを使用して、データを一貫して保存することができます（理にかなっています）。これの良い例は、一貫したロギング、一貫したメンテナンス、機密情報の取り扱いなどだと思います。

データベースの強力なデータモデルに従うアプリケーションのニーズに合わせてデータを操作する他のタスクは、ビジネスロジックを含む別のレイヤーに格納する必要があると思います。要するに、一貫性のためのデータベース固有のデータ操作では、一貫性がデータベース整合性スキーマモデルを超えて拡張されるストアドプロシージャを使用できます。

「for me」のストアドプロシージャは、OLAPの「読み取り専用」操作に適していますが、まれにしか使用されません。

ビジネスルールの場合、OLTPの読み取り/書き込み操作はJavaアプリケーションサーバーを好みます。コーディングを簡単にし、可能な限りマスターデータベースサーバーからCPUとメモリの負荷を軽減します。このセットアップでは、アプリケーションサーバーのすべてのコードを確認または記録することは難しくなく、スケーラブルです。

私にとって重要なことは、ストアドプロシージャをデバッグするよりもビジネスレイヤでデバッグしやすいことです。

ビジネスロジックを不必要に配布し、特定のデータベースベンダーに結び付けることに加えて、私は意図したとおりにテクノロジを使用することも固く信じています。データベースは、リレーショナルデータストアです。それを使用してデータを保存します。

ツールを賢く選択すると、長期的には怪我の世界を救うことができます。