データベースビューがたくさんあっても大丈夫ですか?
-
09-06-2019 - |
質問
まれに (毎月または四半期ごとに) 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'
これはビューを作成するときに留意する必要があることです。ビューは頻繁に参照するデータを保存する方法です。これは、アクセスしやすくするためにデータを整理するための単なる方法です。
ビューは呼び出されたときにのみ CPU/メモリ リソースを消費します。
いずれにせよ、ベスト プラクティスは、統合できるものは統合し、削除できるものは削除することです。また、文字通りレポートでのみ使用する場合は、ビューに一貫した命名標準を選択して、特定のビューを検索するときに簡単にグループ化できるようにすることです。 。
また、トランザクションの分離が本当に必要でない限り、クエリで NOLOCK テーブル ヒントを使用することを検討してください。
-- ケビン・フェアチャイルド
あなたが尋ねる:舞台裏で何が起こっているのでしょうか?
ビューは SQL テキストの束です。クエリでビューが使用される場合、SQL Server はその SQL テキストをクエリに配置します。これは最適化の前に発生します。その結果、オプティマイザは、最適な実行プランを得るために 2 つの個別のコードではなく、結合されたコードを考慮できるようになります。
クエリの実行計画を確認する必要があります。そこでは学ぶべきことがたくさんあります。
SQL Server には、 クラスター化されたビュー. 。あ クラスター化されたビュー システムが管理する結果セットです (基礎となるテーブルに対する挿入/更新/削除により、テーブルに対する挿入/更新/削除が発生する可能性があります)。 クラスター化されたビューのデータ)。ビューが次のような方法で動作すると考えるのはよくある間違いです。 クラスター化されたビュー 操作する。