エンティティフレームワークのストアドプロシージャと生成されたSQLの比較

Question

私はエンティティフレームワークを2つのプロジェクトで使用しました。すべてのプロジェクトで、ストアドプロシージャの利点（セキュリティ、保守性など）のために、エンティティにマップされたストアドプロシージャを使用しました。しかし、ストアドプロシージャの99％は基本的なCRUDストアドプロシージャです。これは、Entity Frameworkの主要な時間節約機能の1つ、つまりSQL生成を無効にするようです。

ストアドプロシージャに関する引数と、Entity Frameworkから生成されたSQLに関するいくつかの引数を読みました。 CRUD SPを使用するとセキュリティが向上しますが、EFによって生成されるSQLは、必要以上に複雑な場合が多く、パフォーマンスやメンテナンス性の点でSPを使用するのは本当ですか？ここで

は私が信じるものである：時間の

• はほとんど、SPを変更することは、とにかくデータモデル を更新する必要があります。だから、保守性の点ではあまり買っていない。
• Webアプリケーションの場合、データベースへの接続では、アプリケーション固有の単一のユーザーIDが使用されます。したがって、ユーザーはデータベースに直接アクセスすることさえできません。これにより、セキュリティのメリットが減少します。
• 小さなアプリケーションでは、 を使用した場合のパフォーマンスが多少低下しても、おそらく大きな問題はありません。 のボリュームが高い場合、パフォーマンスが重要なアプリケーションの場合は、EFでも賢明になるでしょう ？さらに、挿入/更新/削除ステートメントはEFによって実際に生成された ですか？
• ストアドプロシージャにすべての属性を送信すると、パフォーマンスが低下しますが、EF生成コードは実際に変更された属性のみを送信します。大規模なテーブルの更新を行う場合、ネットワークトラフィックの増加とすべての属性の更新によるオーバーヘッドにより、ストアドプロシージャのパフォーマンス上の利点が無効になる可能性があります。言ったことで

、私の具体的な質問は以下のとおりです。

は正しい上記の私の信念はありますか？ ORMが人気を集めている今、SPSを常に「古い学校」なものにする考えはありますか？あなたの経験では、すべての挿入/更新/削除のためにSPをマッピングするか、CRUD操作にEFで生成されたSQLを使用し、より複雑なものに対してはSPのみを使用するEFを使用する方がよいでしょうか？

Answer 1

だと思います。いつも SPはやや古い学校です。私はそのようにコードを作成していましたが、今はEFで生成されたコードでできることはすべてやっています...パフォーマンスの問題やその他の特別な必要があるときは、特定の問題を解決するために戦略SPに追加します。どちらかにする必要はありません - 両方を使用します。

すべての私の基本的なCRUD操作はまっすぐなEF生成コードです。私のWebアプリケーションは100以上のSPを使用していましたが、現在は典型的なものが12個のSPを持ち、その他はすべてC＃コードで行われます。私の生産性は、CRUDに格納されているprocsの95％を排除することで、これまで通りになっています。

Answer 2

パフォーマンスが最も重視される場合は、EF with SPsを使用する既存のアプリケーションのいずれかを使用し、SPを無効にして新しいバージョンをベンチマークする必要があります。それはあなたの状況に完全に適応できる答えを得る唯一の方法です。あなたがしていることが何であっても、カスタムコードと比べてパフォーマンスの必要性が十分に速いわけではありませんが、非常に大量のサイト以外では、EF 4.1はかなり妥当だと思います。

私のPoVから、EFは開発者の生産性を大幅に向上させます。シンプルなCRUD操作のためにSPを記述している場合、特にInsert/Update/Deleteの場合は、SQLを生成するために操作が非常に簡単であるため、パフォーマンスが大幅に向上することはありません。間違いなく、EFが最適なことをしないSelectケースがいくつかあり、SPを書くことでパフォーマンスが大幅に向上することがあります（OracleのCONNECT BYを使用した階層問合せが例として考えられます）。

このタイプの問題に対処する最も良い方法は、EFでSQLを生成させるアプリケーションを作成することです。それをベンチマークする。パフォーマンスの問題がある場所を見つけ、それらのSPを書きます。削除は、これを行う必要があるケースの1つになることはほとんどありません。

あなたが言及したように、ここでは、アプリケーションのアカウントを持っているアプリケーション層にEFをインストールする必要があるため、ここでのセキュリティの向上はいくらか軽減されます。 SPはあなたにもう少しコントロールを与えますが、典型的な使用法では私は重要ではないと思います。

本当に正解か間違った答えがないという興味深い質問です。私はEFを主に使用しているので、一般的なCRUD SPを書く必要はなく、より複雑なケースに取り組むために時間を費やすことができます。 :)

Answer 3

はい、あなたの信念は絶対に正しいです。データ操作のためのストアドプロシージャを使用することは意味があり、主とします

• データベースは、あなたがあなたのエンティティをマッピングするためのビューやカスタムクエリを使用している
• データを変更すると、ストアドプロシージャを通じてのみ許可されている厳格なセキュリティルールに従い、あなたは高度なロジックを必要とします言及した症例の非適用が冗長である純粋CUDの手順を使用し

任意の他の理由で、手順で（データに関連する）いくつかの高度なロジックを有するバック

データをプッシュするストアドプロシージャにそれ単一のシナリオ以外

• を任意の測定パフォーマンスの向上を提供していないあなたは、EFはとても千枚のレコードを変更バルク/バッチ機能は、1000の更新の結果はありません

バッチ/一括変更のためのストアドプロシージャを使用しますそれぞれ別々のデータベース往復で実行されます！しかし、そのようなプロシージャは、とにかにエンティティにマップすることはできず、関数のインポート（可能な場合）または直接ExecuteStoreCommandまたは古いADO.NET（テーブル値のパラメータを使用する場合など）で個別に実行する必要があります。

ストアドプロシージャが独自の最適化されたクエリでデータを読み取るために大幅なパフォーマンス向上を得ることができるCRUDでは、R全体で異なるストーリーをRにすることができます。

Answer 4

私はE.Jに広く同意しますが、他にもいくつかのオプションがあります。特定のシステムの要件に徹底的に徹底的に取り組んでいます。

• アプリを早く開発する必要がありますか？ - 次にエンティティフレームワークとその自動SQLを使用する
• 細かいセキュリティが必要ですか？ - ストアドプロシージャにアクセスする
• できるだけ早く実行する必要がありますか？ - あなたはおそらくいくつかの幸せな媒体を見ているでしょう！

Answer 5

私の意見では、アプリケーション/データベースがパフォーマンス上の問題を抱えておらず、主にCRUDにデータベースを使用しており、1人のDBユーザーしかアクセスできない場合は、生成されたSQLを使用する方が良いです。開発が速く、メンテナンス性が高く、少数のセキュリティやプライバシーの利点がそれほど価値がない（データがあまり敏感でない場合）また、モデルベースのデータベースアクセスやLINQを使用することで、SQLインジェクションによる脅威が無効になりました。