実際のプログラミング言語コードとは異なり、次のようになります。
- 移植性はありません（すべてのデータベースには独自のバージョンのPL/SQLがあります。異なるバージョンの同じ データベースに互換性がありません-私はそれを見ました！）
- 簡単にテストすることはできません-本物が必要です （dev）データベースインスタンスをテストして、ビルドの一部としてコードを単体テストすることは事実上不可能です
- 簡単に更新/解放できない-ドロップ/作成する必要があります。つまり、変更します。 それらをリリースするための本番データベース
- ライブラリをサポートしていない（他の誰かがサポートしているのになぜコードを書くのか）
- 他のテクノロジーと簡単に統合することはできません（それらからWebサービスを呼び出してみてください）
- 彼らはFortranとほぼ同じくらい原始的な言語を使用しているため、有用なコーディングを行うのにエレガントで手間がかかるため、通常はそれが主な目的であるにもかかわらず、ビジネスロジックを表現することは困難です。
- デバッグ/トレース/メッセージロギングなどを提供しないでください（一部のデータベースはこれをサポートしている可能性があります-私はそれを見ていません）
- 構文や他の既存のプロシージャへのリンクを支援するための適切なIDEが不足しています（たとえば、EclipseがJavaに対して行うように）
- それらのコーディングに熟練した人々は、アプリコーダーよりもまれで高価です
- これらの「高性能」は神話です。データベースサーバー上で実行されるため、通常は増加します。 dbサーバーの負荷がかかるため、通常はそれらを使用すると削減されます。 最大トランザクションスループット
- 定数を効率的に共有できない（通常、テーブルを作成し、プロシージャ内からそれを検索することで解決されます-非常に非効率的です）
- など
非常にデータベース固有のアクション（たとえば、データベースの整合性を維持するためのトランザクション内アクション）がある場合、またはプロシージャを非常にアトミックでシンプルに保つ場合は、おそらくそれらを検討することをお勧めします。
事前に「高性能」を指定する場合は注意が必要です。それはしばしば良いデザインを犠牲にして悪い選択につながり、あなたが思っているよりもずっと早くあなたを噛むでしょう。
自分の危険でストアドプロシージャを使用します（そこにいて、二度と戻りたくない人から）。私の推奨は、疫病のようにそれらを避けることです。