Microsoft SQL Server 2005データベースビューを使用して、数百のCrystal Reportsレポートを生成することはめったにありません（月次/四半期）。それらのビューは、私がそれらから読み取っていない間、CPUサイクルとRAMを浪費していますか？ビューから読み取ることはめったにないので、代わりにストアドプロシージャ、一時テーブル、または短期間の通常のテーブルを使用する必要がありますか？
私はDBAではないので、データベースサーバー内の舞台裏で何が起こっているのかわかりません。
データベースビューが多すぎる可能性はありますか？ベストプラクティスとは何ですか？
ほとんどの場合、それは問題ではありません。はい、SQL Server は SELECT * FROM テーブルを解析する際により多くの選択肢があります (システム カタログで「テーブル」を検索する必要があります) が、そのために高度に最適化されており、十分な RAM があれば (最近のほとんどのサーバーはそうしています) 、0 と 1,000 のビューの違いに気付かないでしょう。
ただし、人間の観点からは、「数百」のビューが何を行っているかを管理および把握しようとすることはおそらく不可能であるため、多くの重複したコードが存在する可能性があります。これらの冗長なビューに埋め込まれている一部のビジネス ルールが変更された場合はどうなりますか?
ビューの主なポイントは、ビジネス ロジックを疑似テーブルにカプセル化することです (そのため、person テーブルを使用することもできますが、"active_persons" と呼ばれるビューが魔法のように機能します)。各レポートのビューを作成することは、各レポートが非常に分離され、一意であり、再利用できない場合を除いて、ちょっとばかげています。
ビューは、事前設定されたパラメーターを使用して頻繁に実行するクエリです。常に同じデータを参照することがわかっている場合は、使いやすさとデータ バインディングのためにビューを作成できます。
そうは言っても、ビューから選択すると、実行中のクエリとともにビューを定義するクエリが実行されます。
たとえば、vwCustomersWhoHavePaid が次の場合:
Select * from customers where paid = 1
実行しているクエリは、8 月 1 日以降に支払いを行った顧客を次のようにフォーマットして返します。
Select * from vwCustomersWhoHavePaid where datepaid > '08/01/08'
実際に実行しているクエリは次のとおりです。
Select * from (Select * from customers where paid = 1) where datepaid > '08/01/08'
これは、ビューを作成するときに覚えておくべきことです。ビューは、頻繁に見るデータを保存する方法です。これは、アクセスしやすくするためにデータを整理する方法にすぎません。
あなたは尋ねます：舞台裏で何が起こっているのですか？
ビューは一連の SQL テキストです。クエリがビューを使用する場合、SQL Server はその SQL テキストをクエリに配置します。これは最適化前に発生します。その結果、オプティマイザは最適な実行計画のために、2 つの個別のコードではなく、結合されたコードを考慮することができます。
クエリの実行計画を確認する必要があります。そこには学ぶべきことがたくさんあります。
SQL Server には、クラスター化されたビューの概念もあります。クラスター化されたビューは、システムが管理する結果セットです (基になるテーブルでの挿入/更新/削除のたびに、クラスター化されたビューのデータの挿入/更新/削除が発生する可能性があります)。ビューがクラスター化されたビューのように動作すると考えるのはよくある間違いです。
ビューは、呼び出されたときにのみ CPU/メモリ リソースを消費します。
とにかく、ベスト プラクティスは、統合できるものを統合し、削除できるものを削除することです。文字通りレポートでのみ使用される場合は、ビューに一貫した命名基準を選択して、特定のビューを探すときに簡単にグループ化できるようにします。 .
また、トランザクションの分離が本当に必要でない限り、クエリで NOLOCK テーブル ヒントを使用することを検討してください。
-- ケビン・フェアチャイルド