私はいくつかのプロジェクトでエンティティ フレームワークを使用しました。すべてのプロジェクトで、ストアド プロシージャをエンティティにマップして使用しました。これは、ストアド プロシージャのよく知られた利点 (セキュリティ、保守性など) によるものです。ただし、ストアド プロシージャの 99% は基本的な CRUD ストアド プロシージャです。これは、エンティティ フレームワークの主要な時間節約機能の 1 つである SQL 生成を無効にしているように思われます。
ストアド プロシージャと Entity Framework から生成された SQL に関する議論をいくつか読みました。CRUD SP を使用する方がセキュリティの面で優れており、EF によって生成された SQL は必要以上に複雑になることが多いのですが、パフォーマンスや保守性の面で SP を使用することで本当に何かメリットがあるのでしょうか?
私が信じていることは次のとおりです。
- ほとんどの場合、SP を変更するには、いずれにしてもデータ モデルを更新する必要があります。そのため、保守性という点では大きなメリットはありません。
- Web アプリケーションの場合、データベースへの接続にはアプリケーション固有の単一のユーザー ID が使用されます。そのため、ユーザーはデータベースに直接アクセスすることすらできません。これにより、セキュリティ上の利点が減少します。
- 小規模なアプリケーションの場合、生成された SQL を使用することでパフォーマンスがわずかに低下しても、それほど問題にはならないでしょう。しかし、パフォーマンスが重要となる大容量のアプリケーションの場合、EF は賢明な選択でしょうか? また、EF によって生成される挿入/更新/削除ステートメントは本当にそれほど悪いのでしょうか?
- すべての属性をストアド プロシージャに送信すると、パフォーマンスが低下しますが、EF で生成されたコードは、実際に変更された属性のみを送信します。大きなテーブルを更新する場合、すべての属性を更新することでネットワーク トラフィックが増加し、オーバーヘッドも増加するため、ストアド プロシージャのパフォーマンス上の利点が打ち消される可能性があります。
そうは言っても、私の具体的な質問は次のとおりです。
上記の私の考えは正しいでしょうか? ORM が人気を集めている現在、常に SP を使用するという考え方は「古い考え方」なのでしょうか? あなたの経験では、EF を使用するには、挿入/更新/削除のすべてに SP をマッピングするのと、CRUD 操作に EF で生成された SQL を使用し、より複雑な操作にのみ SP を使用するのとでは、どちらがよいのでしょうか?
ベストアンサー1
私は思ういつもSP を使用するのは、やや古いやり方です。私は以前そのようにコーディングしていましたが、今では EF で生成されたコードでできる限りのことを行っています...そして、パフォーマンスの問題やその他の特別なニーズがある場合は、特定の問題を解決するために戦略的な SP を再度追加します...どちらか一方である必要はありません。両方を使用してください。
私の基本的な CRUD 操作はすべて、EF で生成されたコードです。以前は Web アプリに 100 個以上の SP がありましたが、今では一般的なアプリには 12 個の SP があり、その他はすべて C# コードで実行されます。また、CRUD ストアド プロシージャの 95% を排除することで、生産性が大幅に向上しました。