私のデータベースの新しいテーブルデザインを検討しているので。最終的な計算をテーブルの列に保存するか、作成する予定のビューで計算するかの間で、私は引き裂かれています。たとえば、ある列に値10を格納し、別の列に5を格納し、別の列に（10/5）を格納したい場合は、5を独自の列に格納するか、計算する方がよいと思います。計画されたビューでそれ？
このテーブルには、おそらく1年ほどの間、1日あたり約40万件のレコードが含まれます。単純なデータ型を使用してストレージコストを削減できますが、それでも、レコードごとにさらに4バイトのデータを維持する必要があります*同じ行に計算されたレコードがいくつあるか。
数日間のデータについて、計算値に対してクエリを実行します。それでも速度が必要ですが、データベースが小さく、テーブルの保守が簡単で、ビューの柔軟性も必要です。
あなたの見解や考えは何ですか？
データの整合性が最も重要です。
ビューで結果を計算すると、最新の回答が得られることが保証されます。トレードオフは、特に結果が WHERE 句で使用される場合の SELECT ステートメントの実行時のパフォーマンスです。私の経験では、計算の結果が WHERE 句で使用されることはほとんどありません。計算とは、算術演算だけでなく、文字列と部分文字列の抽出と連結、チェックサム計算などを意味します。
計算結果をベース テーブルに格納すると、SELECT のパフォーマンスが最高になります。トレードオフはデータの整合性です。結果が常に正しいことを保証する CHECK() 制約を記述できる場合は、それを行う必要があります。しかし、複雑な計算に対する CHECK() 制約は、ユーザー定義関数を使用しないと表現できない場合があり、すべてのプラットフォームが CHECK() 制約でユーザー定義関数をサポートしているわけではありません。
CHECK() 制約を記述できない場合でも、データのエラーを定期的にチェックする何らかの手順が必要です。最悪の場合、需要が少ないときに毎日または毎週レポートを実行できます。
マテリアライズド ビューは、両方の長所を活用できる可能性があります。つまり、検索可能な WHERE 句の対象となり、常に正しいことが保証される計算です。(SQL Server に相当するものはインデックス付きビューと呼ばれます。) トレードオフは、ストレージ スペースと、実体化されたビューとそのインデックスをベース テーブルの更新後に最新の状態に保つために必要な CPU サイクルです。
通常、最初にビューを試します。しかし、あなたの特定のケース (365 日間、1 日あたり 40 万行) では、最初に具体化されたビューを試してみると思います。何らかの理由でうまく機能しない場合は、ベース テーブルの列に置き換え、マテリアライズド ビューを削除し、同じ名前の新しいビューを作成できます。(論理データの独立性は揺るぎません。)
計算された値に対してクエリを実行します...
私はどのように？
1 CPU を少し増やすと、ストレージ要件が減るため、キャッシュの有効性が向上し、ほとんどの OLTP ワークロードで最も重要なパフォーマンスのボトルネックになりがちな I/O が減少します。結果をキャッシュすることは、計算にコストがかかる場合に正当化されますが、単純な除算はそのしきい値からはほど遠いものです。
2テーブル内で通常のフィールドとして、または永続化された計算列として、またはマテリアライズド/インデックス付きビューで。
開発環境がある場合は、両方の方法をテストし、作業/メンテナンス コストあたりのパフォーマンスが最も高い方法を選択することをお勧めします。テーブルに最大 40 万件のレコードが格納されている場合でも、そのデータへのアクセス方法によっては、1 つの方法の方が理にかなっている場合があります。