1

sum()合計値をフィールドに保存することと、別のテーブルで操作を実行することの長所と短所について疑問に思っています。例として、アイテムのリストと各アイテムの購入数を取得することが挙げられます。この場合、 購入を合計する必要があるItemsテーブルとテーブルを持つことができます。Purchases

合計値の利点:

  • よりシンプルで高速な SQL ステートメント (などはJOIN不要Items.item_id=Purchases.item_id)

の長所sum():

  • UPDATE 値を変更するにはと INSERTステートメントの両方が必要なため、値を取得するために 2 つの方法を維持する必要はありません(たとえば、テーブルINSERT内の購入のと のフィールドのなど) 。PurchasesUPDATEpurchase_countItems
4

2 に答える 2

2

そのような質問に対する正しい答えはありません。答えは、データの使用方法に完全に依存します。

両極端。データをめったにクエリせず、履歴データに多くの変更がある場合、システムは必要のない合計を一貫して維持するために多大な労力を費やす可能性があります。

一方、データが「挿入のみ」であり、すべてのレコードが合計で繰り返し取得される場合は、合計を取得することで労力を節約できます。

一般に、より正規化されたアプローチ、つまりsum()、ビジネス ルールとして保持するよりも、クエリ時に実行する傾向があります。明らかな利点の 1 つは、値が長期的に一貫していることです。

2 つ目の利点は、分析が変化する可能性があることです。多分今日はアイテムの数が必要です。たぶん来週、ユニット数が必要になるでしょう。そしてドルのカウント。または正味価格差。これらは時間とともに変化します。それらすべてを事前に把握しようとするのは困難です。ここでの解決策は、問題を 2 つに分割することです。正規化されたデータ (魔法の合計なし) を 1 つの「データベース」に格納します。エンド ユーザーの目標に合わせて変更できる「データ マート」に要約を保存します。データ マートは定期的に (1 日 1 回または 1 週間に 1 回) 更新されます。

期間の要約を含む正規化された基本データは、多くのニーズを満たす強力なアーキテクチャです。しかし、 onではなく // でinsert計算を行う方が実際には良い考えである場合もあります。このような解決策は、多くの場合、はるかに複雑になるため (インスタンスの複数のトリガー)、より正規化された解決策よりも強力に正当化する必要があります。updatedeleteselect

ウィキペディア: データベースの正規化

于 2013-06-11T11:41:37.053 に答える
1

アプリケーションの性質と使用法によって異なります。

どのクエリがより頻繁に使用されているかについて、計算を行うか、(既存のアプリケーションの場合) 使用法を確認する必要があります。クエリの DML タイプ:

  • 合計値アプローチ:SELECTアイテムを閲覧し、アイテムに関する情報を表示するためのより多くのクエリに適しています (通常の e ショップなど)。
  • sum() アプローチの使用:UPDATE/INSERTより多くのクエリに適しています。たとえば、主に店舗在庫の管理で構成される重い店舗アプリケーションです。
于 2013-06-11T10:08:35.400 に答える