ビュー(他の人が示唆しているように)またはインラインテーブル値関数を選択します(これの利点は、日付範囲や顧客アカウントなどのパラメーターが必要であることです。これにより、ユーザーが制限なしでクエリを実行するのを防ぐことができます問題空間) 最初に。インライン TVF は、実際にはパラメーター化されたビューであり、エンジンがそれらを処理する方法という点で、パフォーマンスが非常に低くなる複数ステートメントのテーブル値関数やスカラー関数よりもはるかにビューに近いものです。
ただし、ビューが複雑または集約的である場合、場合によっては、これが本番パフォーマンスに影響を与える可能性があります。適切に作成されていないアドホック ユーザー クエリを使用すると、より適切に作成されたクエリよりもロックが長く持続したり、さらにエスカレートしたりする可能性があります。また、ユーザーが ER データ モデルを誤って解釈し、多対 1 または多対多の関係がある場合に乗算された数値を生成する可能性もあります。次のオプションは、インデックスを使用してこれらのビューを具体化するか、テーブルを作成してそれらを更新し続けることです。これにより、次のオプションに近づきます...
したがって、ビュー オプションのこれらの欠点と、データのコピーを作成することで軽減することを既に考えていることを考えると、次に検討するオプションは、異なる構造のデータの別の読み取り専用 (これらのユーザー向け) バージョンを用意することです。 . 通常、私は最初に Kimball スタイルのスター スキーマを調べます。完全な時間整合性データ ウェアハウスは必要ありません。もちろん、それはオプションですが、レポート モデルを最新のデータに保つこともできます。スター スキーマは非正規化の特殊な形式であり、特に数値レポートに適しています。特定のスターがユーザーによって誤って悪用されることはありません。トリガー、スケジュールされたジョブなど、さまざまな方法でスターを最新の状態に保つことができます。
このようなソリューションでは、実質的に 2 倍以上のストレージ要件が必要になる場合がありますが、データをよく理解し、トランザクション用と分析用の 2 つのモデルを使用することを気にしない場合、他の方法と比較すると、非常に優れたオプションになる可能性があります。 (ビューの最も単純な最初のオプションを使用して、とにかくこの論理的な分離をすでに開始していることに注意してください)。
一部のアーキテクトは、多くの場合、サーバーを 2 倍にし、何らかのレプリケーションを使用して SAME モデルを使用して、より頻繁に、または異なる方法でインデックスが作成されたレポート サーバーを提供します。このような 2 番目のサーバーは、レポート要件のある運用トランザクションに影響を与えず、かなり簡単に最新の状態に保つことができます。モデルは 1 つしかありませんが、もちろん、これにはユーザーが独自のプレイグラウンドを取得するため、パフォーマンスに影響を与えることなく、基礎となるモデルのみにアドホックにアクセスできるようにするという同じユーザビリティの問題があります。
これらの猫の皮をむく方法はたくさんあります。幸運を。