データベースビューを介して挿入および更新することは悪い習慣ですか？
現在、カスタムメイドのORMフレームワークをEntity Framework（EF）に徐々に置き換えています。手順の1つは、現在のORMと同じように、EFを使用してデータベースビューを介してレコードを更新および挿入できることを確認することです。ビューは、ユーザーのアクセス可能なレコードをフィルタリングすることでセキュリティを提供し、アクセスと他のレコードを更新する可能性を防ぎます。
私はEFでこのアプローチを適切に実装する方法をしっかりと理解できず、これらのビューを介して更新および挿入（場合によっては削除）するのが良い習慣であるかどうかを自問し始めました。私がググると、このテーマに関する良い/悪い実践の推奨事項が見つかりません。他の人がこのアプローチを使用することもあります。多分私の検索スキルは十分に洗練されていません。
私には、ビューは読み取り専用であり、ユーザーが潜在的に複数のテーブルからデータをすばやく選択できるようにすることを意図しているようです。それが可能であるにもかかわらず、ビューで挿入または更新を実行すると、その理由で気分が悪くなります。
ビューを使用してレコードを挿入および更新する利点と欠点は何ですか？
また、Entity Frameworkを提供する際に特定の問題はありますか？
これまでに見つけたもの。利点：
- データベースレベルでアクセス可能なレコードをフィルタリングすることによるセキュリティ
- 一括挿入はビューに対しても機能します
短所：
- レコードを更新または挿入する必要がある場合、Selectステートメントは多かれ少なかれロックされます
- EFに固有で、マイグレーションを使用する場合、ビューを突然、テーブルではなくビューとして扱う必要があります。 （私が間違っていたら訂正してください）
いくつかの情報：
- EF 6.13を使用します
- MSSQLデータベースです
- 読み取り専用ビューとCRUDビューの両方があります
- 一部のビューはひどいパフォーマンスを示します。主に、ビューでCRUD操作を実行する必要があるためにビューを変更できないためです。
- 約30のビューがあります
ここがこの質問をする正しい場所であることを願っています。
この件について知っておくべきことはすべて、 このMicrosoftの記事 にあります。
具体的には：
ビューを介してクエリを実行する場合、データベースエンジンは、ステートメント内のどこかで参照されているすべてのデータベースオブジェクトが存在すること、それらがステートメントのコンテキストで有効であること、およびデータ変更ステートメントがデータ整合性ルールに違反していないことを確認します。失敗したチェックはエラーメッセージを返します。チェックが成功すると、アクションが基になるテーブルに対するアクションに変換されます。
つまり、ビューに対して行うデータ変更操作は、基盤となるデータベーススキーマにすでに課している制約に準拠する必要があります。さらに、ビュー自体が提供するすべての許可規則の恩恵を受けることができます。 EFは基本的に他のテーブルと同じようにビューを扱うため、多くの利点があり、欠点はほとんどありません。
当然のことながら、パフォーマンスが低いビューなど、このアプローチで問題が発生した場合は、そのような場合にダイレクトテーブルに戻すか、編集目的でより適切なビューを作成する必要があるかどうかを評価できます。