私は最近.NETのEntityFrameworkを頻繁に使用しており、ストアドプロシージャの使用に戻ることは絶対に望んでいません。私がこのプロジェクトを構築している会社には、ストアドプロシージャにアクセスするためのアクセス許可しか持たないアカウントのみがアプリケーションに与えられるというポリシーがあったことに、ショックを受けました。
どうやら、彼らは、アプリケーションがテーブル/ビューに直接アクセスできるようにすることにはセキュリティリスクがあると信じています。わかりません。
考えてみると、特定のコンテキストでは、ストアド プロシージャへのアクセスを制限することは非常に理にかなっています。プロシージャは API を公開し、処理 (複雑な制約のチェックなど) を処理しますが、これは理論的には問題ありません。「列 A が null の場合、列 B は {X, Y, Z} のいずれかにする必要がある」など、列間の制約を宣言する簡単な方法はありません。複数のアプリケーションがプロシージャー API を使用している可能性があり、データが正しい方法で処理されるようにするプロシージャーはすべてのアプリケーションにメリットをもたらします。
ただし、データベースに大量のロジックを記述し、汎用 OOP 言語に多数のロジックを記述しようとしたことのある人なら誰でも、前者は保守不可能で DB ロックされた理解不能なコードの山につながる傾向があり、後者は一般に認識されていることを知っています。 「複雑なアプリケーション/システムを書く方法」として。
ストアド プロシージャ API のアプローチが消滅したわけではありませんが、このパターンを使用して新しいプロジェクトが開始されたのを見ると、本当に驚きます。ORM は完璧にはほど遠いですが、ますます当然のことと思われている大きな利点を提供します。アプリケーション全体を1 つの言語 (Python、Java、Groovy、Ruby...) で記述でき、通常は DBMS を別の言語に切り替えることができます。数分 (たとえば、hsqldb でテストを実行しているが、本番環境では postgresql を使用している場合)、データベースとの間のデータのパッケージ化は非常に簡単です (ORM は通常、プリミティブではなくドメイン オブジェクトを返します)。キャッシングのメリットなど
このことを考慮すると、アプリケーションがそのデータベース内のすべてに完全な CRUD アクセスを持っていることはまったく問題ありません。また、ストアド プロシージャの呼び出しのみを許可するアカウントをお持ちの場合は、アクセス権を回避する方法を調べることに時間を費やすことはお勧めしません。時間を有効に使うには、CRUD テーブル アクセス権について議論することをお勧めします。
ばかげた制限された思考 - データベースに完全なアクセス ロジックを入れない限り。
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
セキュリティが理由ではない理由についての良い説明があります。私が言ったように - 誰がデータベースに何があるかを検証する完全なビジネスロジックを除いて....それはもはや多層アプリケーションではありません.