0

フィールドXとフィールドDATEを持つSQLテーブルを作成しました。DATE<dであるXの合計を計算したいと思います。私には2つの可能性があります:

  • 新しいフィールド「sumofX」を作成します。これは、date<date[field]の場合のXの合計を表します。
  • SQLリクエストを使用して、Xの合計を「手動で」計算します

常に優れた方法はありますか?または、そうでない場合は、テーブルのサイズに依存すると思います。2つの方法を等しくするおおよそのサイズはどれくらいですか?

どうもありがとうございます。

4

2 に答える 2

2

常に優れた方法はありますか?

いいえ。しかし、一般的には、それが機能しなくなるまで、最も単純な解決策を使い続けてください。この場合の最も簡単な解決策は、必要になるたびに派生フィールドを計算することです。

または、そうでない場合は、テーブルのサイズに依存すると思います。

はい。そして、挿入の数対読み取りの数。そして、日付が単調に増加しているかどうか。また、システムとその要件のスペース(メモリ/ディスク)と時間(処理能力)のトレードオフ。そして、おそらく他にもたくさんあります。

2つの方法を等しくするおおよそのサイズはどれくらいですか?

紐の長さはどれくらいですか?それに答えるには他の変数が多すぎます。

繰り返すには:他の方法で強制されるまで、単純なままにします。キャッシュされた値を維持すると、複雑さとコーナーケースが発生します。トランザクションの境界は何ですか?新しい行を追加するとどうなりますか?これにより、影響を受ける行を検出して更新するための後続のトランザクションがトリガーされると考えられます。その後、元のトランザクションをロールバックするとどうなりますか?

それはもっと多くの論理です。うまくいかない可能性がはるかに高くなります。あなたがそうするのを見つけるまで、 YAGNIに固執してください。

hth。

于 2013-02-08T00:46:34.947 に答える
0

データの不整合を避けるために、計算フィールドを保存しないでください。そのような質問がある場合は、モデルについて考え、この質問を廃止するように進化させる必要があるかどうかを検討してください。

于 2013-02-08T13:48:59.837 に答える