クエリから取得できるデータを保持する新しいテーブルをいつ作成するかをどのように特定できますか？

支払い表があり、エージェントは支払いの手数料を受け取ります。コミッションは、支払いを取得するのにかかった時間など、いくつかの異なる要因に基づいているため、エージェントが取得するコミッション率を計算する際にはいくつかの計算が必要ですが、わいせつな複雑さはありません。

たとえば、おそらくこれより複雑になることはありません。

SELECT Payments.Amount * CASE 
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 1 THEN Rates.Rate1
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 2 THEN Rates.Rate2
    ELSE Rates.Rate3 END

必要なときにいつでもクエリを実行するのではなく、このデータを保持する2番目のテーブルを作成するのは理にかなっていますか？それとも、要求されたときにデータをプルするランタイムクエリをそのまま使用する必要がありますか？

さらに重要なことに、データが必要なときにクエリを実行する必要があるかどうか、またはデータを独自の別のテーブルに格納する必要があるかどうかを判断するときに使用する要素は何ですか？

sql-server sql-server-2005 query-performance

— レイチェル
ソース

重要な質問の1つは、「このデータに対してクエリを実行する頻度はどのくらいか？」です。それはレポートですか、それともアプリケーションで大量にトラフィッキングされた画面ですか？

— ConcernedOfTunbridgeWells

@ConcernedOfTunbridgeWellsこの場合、これは1か月に数回実行されるレポートです。おそらく、エージェントがレポートを自分で実行してコミッションを表示できるようにすると、もっと頻繁になります。

— Rachel

おそらく、それを夜間プロセスのレポートテーブルに組み込むのが最善であり、委員会は「昨夜の時点」です。終了する必要のある終了プロセスがある場合は、レポートを作成して、アプリに強制的に再構築する機能を提供できます。

— ConcernedOfTunbridgeWells

私の経験では、 "AsOf"の日付は、金融のコンテキストでこれらの種類の操作にかなり一般的です。したがって、そのような "AsOf"日付を持つテーブル（@ConcernedOfTunbridgeWellsの注釈）は完全に受け入れられるはずです。

— swasheck 2012年

関連記事：dba.stackexchange.com/q/7592/2660

— Nick Chammas

回答:

クエリの実行頻度がかなり低い場合（レポートなど）、その場でテーブルを構築する方が適切です¹。クエリが頻繁に実行され、一時テーブルがパフォーマンスに必要な場合は、問題が発生している可能性があります。

テーブルが安価に作成できる場合は、一時テーブルとして作成します。データベースが十分に高速である限り、それでうまくいくかもしれません。ただし、パフォーマンスを監視する必要があります。
テーブルが完全に最新である必要はないが、比較的頻繁なレポートアクティビティの対象になる場合は、定期的な再構築がおそらく最善の方法です。
テーブルの作成にはコストがかかりますが、最新の状態にする必要がある場合は、インデックス付きビューとして、またはトリガーを介して、非正規化された構造として管理する必要があります。これはかなり複雑で、書き込み操作に追加の負担をかけます。

より極端なケース（つまり、大量のデータ）では、パフォーマンスに最適化された非正規化構造から履歴データがクエリされ、ライブアプリケーションから現在のデータがクエリされるハイブリッドアプローチが必要になる場合があります。

これの最も極端なケースでは、低レイテンシのデータマートフィードとハイブリッドOLAPソリューションを利用できるため、これは、ウサギの穴の深さの点ではるかに複雑です。真の要件がない限り、回避することをお勧めします。

上記の場合、レポートテーブルの定期的な再構築が適切に聞こえます。レポートを実行するために1日の途中で閉じる必要がある場合は、アプリケーションから強制的に更新する機能を提供できます。それ以外の場合は、夜間プロセスで実行すると、エージェントは「前の営業日の午前0時」と同様にコミッションを確認できます。

select into一時テーブルを作成する^1つのクエリは、挿入操作のログが最小限であるため、SQL Serverでは非常に高速です。

要約すると、次の要素を使用して、データ用の新しいテーブルを作成する必要があるかどうかを判断します。

データが必要とされる頻度
データを取得するのにどれだけ費用がかかるか
データを最新にする必要があるか

— ConcernedOfTunbridgeWells
ソース

したがって、基本的に、必要なときにクエリを実行するのではなく、データの永続テーブルが必要かどうかを判断する際に使用する唯一の2つの要素はhow often the data is needed、how expensive the query is？

— レイチェル

@レイチェル-また、「データはどの程度最新のものである必要がありますか？」

— ConcernedOfTunbridgeWells 2012年

受け入れられた回答でカバーされていない1つの問題は、「時間の経過とともにこの値が必要ですか」および「式が変更される可能性があります」です。

たとえば、コミッションの例を考えてみましょう。コミッションが支払われた場合、実際に支払われた金額の履歴値であるため、金額は保管されます。コミッションを計算する方法は、来月変更される可能性があります（頻繁に変更されます）が、実際に支払われる金額は変わりません。

これは、顧客が実際に製品に支払った価格（割引の計算後など）を格納するのと同じ考え方です。翌月の製品の価格は、顧客が注文したときの価格と同じです。

ある時点での値の履歴記録が必要な場合は、初期計算の式を使用した後、常にその値を保存してください。

— HLGEM
ソース

ありがとう、それはこの種の決定をするときに間違いなく考慮すべきことです。今回は、クライアントが取得されたときに、コミッションレートがエージェントごとおよびクライアントごとに1回設定され、使用されるレートが支払い日とクライアントを受け取った日付に基づいているため、値は変化しません。変化する値です。

— レイチェル

@Rachel-どちらも現在変更する予定の値ではありません。もちろん、彼らがあればやるの変化をあなたは常に限り、あなたは問題を忘れないでくださいと、あなたがそれを必要とする場合、その時点で過去のデータテーブルを作成することができます。

— psr 2012年

特定のデータベースにロックされている場合はおそらく関心がありませんが、MariaDB（MySQLベースの動作に似ています）には、「仮想列」と呼ばれる素晴らしいものがあり、オンザフライで計算するか、実際のストレージにキャッシュできますが、自動的に行われます。必要に応じて再計算されます。何年も前にFileMaker ProをSQLの世界に残して以来、この機能を見逃してしまいました...

— ヤン・スタインマン
ソース