1

私は現在、「Microsoft SQL Server 2012、第3版でビジネスインテリジェンスを提供する」という本を読んでいます。この本には、次のようなセクションがあります。

データマートの機能

データマートは、組織の日常のトランザクションを管理するのではなく、ビジネスインテリジェンスのソースとして機能することを目的としているため、OLTPデータベースと同じように設計されていません。データマートは、正規化のルールに基づいて構築されるのではなく、アクセス速度を重視して構築されています。データマートは依然としてリレーショナルデータベースですが、分析とレポートのためにデータを出力するときに必要なテーブル結合が少なくなるように設計されています。データマートでは、速度を上げるためにデータを繰り返し（非正規化）することができます。

データマートを設計する場合、正規化のルールは、「事実」を中心に編成された別の設計方法に置き換えられます。これらの新しい設計アプローチは、星と雪片と呼ばれます。「スタースキーマ」と「スノーフレークスキーマ」のセクションで、星と雪片について説明します。星や雪片は子供の空想のようなもののように見えるかもしれませんが、実際には、すばやく簡単にアクセスできる情報を作成するための非常に成長した現実的なアプローチを提供します。

なんて素晴らしい情報でしょう。しかし、ここから混乱が生じ始めました。SQLServerでは、クエリのパフォーマンスを最適化する方法としてストアドプロシージャを使用できることを知っています。これらの内部動作はわかりませんが、サーバーには、従来の正規化されたデータベースでクエリをすばやく実行するためにクエリのパフォーマンスを最適化する方法が組み込まれていることを知っています。たとえば、販売されたすべての個別の製品である20,000行のリストを含むSalesテーブルがあるとします。これらの行の合計を知りたい場合は、おそらくクエリSELECT SUM(SALES.SALESPRICE) FROM SALESをストアドプロシージャに保存します。

ストアドプロシージャがプリコンパイルされていることがわかっている場合、サーバーは、挿入が行われるたびにこの合計を取得してクエリの結果をキャッシュする必要があることを自動的に認識しませんか？したがって、20,001行が追加されるたびに、販売額が自動的に保存されるため、上記のストアドプロシージャの結果をすぐに利用できますか？それが実行計画の背後にある全体的な考えではありませんか？または、「最適化された」クエリが行うことを完全に見逃しましたか？

そうでない場合は、ストアドプロシージャの内部動作と、SQL Server Management Studio（SSMS）から直接クエリを実行するよりもパフォーマンスが向上する方法を理解していただければ幸いです。

ありがとうございました！！！！

4

3 に答える 3

2

はい、あなたはむしろ要点を逃しました、私は恐れています。

ストアドプロシージャの利点の1つは、結果とは対照的に結果を取得する方法を計算するのにも処理時間がかかることです。これがストアドプロシージャによってキャッシュされます。execution plan

http://www.simple-talk.com/sql/performance/execution-plan-basics/を参照してください

おそらく、ストアドプロシージャの大きな利点は、データへのアクセスをよりきめ細かく保護し、外部（SP）インターフェイスを変更せずにスキーマを非表示または変更できるINSERTことUPDATEですDELETE。データ。同様のタスクまたは複数のタスクを実行する特定のプロシージャへのアクセスを許可するだけです。

合計計算の結果を保存したい場合は、それを行うことができますが、専用のテーブルに保存するか、合計をグループ化する場合は既存のテーブルの追加フィールドに保存する必要があります。INSERT、UPDATEおよびイベントのトリガーで、またはこれらのデータ操作機能を実行するために作成するストアドプロシージャの追加コードによって、手動でDELETE作成する必要があります。したがって、ストアドプロシージャは次のようになります。

create proc SellProduct (@productID int, @price money)
as
begin
    insert ProductSales (ProductID, SalePrice) values (@productID, @price)
    update Products set TotalSales = TotalSales + @price WHERE productid = @productID
end

（そして、上記のコードを完成させる前に、トランザクションについて読みたいと思うでしょう）

于 2012-09-06T08:12:32.610 に答える
1

それで、あなたの質問はストアドプロシージャに関するものであるため、MDXタグを削除しました。あなたは、質問を例示するためにOLAPを使用しているだけです。

したがって、ストアドプロシージャがプリコンパイルされていると言う場合、これはプロシージャの結果には適用されないことに注意してください。select（sum）を使用するプロシージャがある場合、それを実行するたびに、select（sum）がデータベースに送信されます。結果はどこにも保存されません。

パフォーマンス上のメリットについておっしゃいました。プロシージャ内でクエリをラップしても、パフォーマンス上のメリットはありません。舞台裏では、クエリはproc内にあるかどうかに関係なく、正確に実行されます。手順の利点は、@podiluskaが言ったより関連しています。

あなたの主な混乱（この行に基づいてあなたが書いWhenever line 20,001 is added, the amount of the sale would automatically be saved so the result of the above stored procedureた:)は、手続きがデータを含むオブジェクトであると考えていることであり、そうではないと思います。プロシージャ、ビュー（非永続的）、および関数は、クエリまたはデータを改善するために使用するメカニズムです。

于 2012-09-06T08:23:54.667 に答える
1

OLAPは、データマート内に100万の異なるSUMの結果を格納します。OLTP（「通常の」SQLデータベース）は、基になるデータのみを格納し、ストアドプロシージャを呼び出すときにSUMを計算します。

ストアドプロシージャは、Cプログラムのようにコンパイルされます。プロシージャの外部で記述したSQLクエリは、ASP Webページのように、実行時に変換されます。どちらにもデータは含まれていません。

于 2012-09-11T21:19:44.947 に答える