SQLのプログレッシブ合計

Question

I次の表があります。

CREATE TABLE tbl_proc(
    [proc] float, 
    subscriber bigint 
) 

データ：

proc | subscriber 
-----|----------- 
0.7 | 123456 
0.5 | 1234567 
0.3 | 12345  
0.3 | 45678  
0.3 | 1234 
0.2 | 123455 
0.1 | 894562 

私は和を表し、テーブルに新しい列を追加するための良い方法を見つけたいです上記の値。

結果：データはPROCでDESCをソートされ、私のテーブルでは

Select a.[proc],SUM(b.[proc]) 
from tbl_proc a, tbl_proc b 
where a.[proc] <= b.[proc] and (a.[proc] <> b.[proc] or a.subscriber >= b.subscriber) 
group by a.[proc],a.subscriber 
order by a.[proc] desc 

：

proc | subscriber | col3 
-----|------------|------------ 
0.7 | 123456  | 0.7 
0.5 | 1234567 | 1.2 -- 0.7 + proc 
0.3 | 12345  | 1.5 
... 

私は、次のような方法を見つけました。また、加入者列は一意です。

私が見つけたこの方法は、ちょっと高価すぎる（テーブルが大きい）。 パフォーマンス上の理由から、カーソルのようなソリューションは考慮していませんでした。

提案がありますか？

---

更新：

http://geekswithblogs.net/Rhames/archive/2008/10/28/calculating-running-totals-in-sql-server-2005---the-optimal.aspx

限り：私は少し問題をGoogleで検索し、私はこのページのソリューション「ローカル変数へのアップデート」を見つけ

私がこれをテストしたところ、今のところ最高の解決策であることがわかります。

宣言@runningTotalフロート= 0

UPDATE tbl_proc SET @RunningTotal = new_col = @RunningTotal + [PROC]

tbl_proc

Answer 1

FROMこれは、一般的に実行されている合計を計算として知られています。

「quirky update」と呼ばれる操作を実行する方法は非常に高速ですが、文書化されていない動作に依存しています。

これらのカーソル以外は、大きなワークセットのワークロードが直線的に増加するため、最も高速な方法ですが、三角形の結合ワークロードは指数関数的に増加します（次のバージョンおよびthe improved OVER clauseまで）。

この問題の詳細については、Itzik Ben Ganのthis documentを参照してください。

Answer 2

他にもあります。これは確かに正規化されていません。
注文の順序はあいまいです。

私があなただったら私はこれを避けるでしょう。代わりにこれを動的に返すビューまたはクエリを記述します。

Answer 3

カーソルはあなたにとって良い選択肢です。彼らは常に悪いわけではありません。実際、特定の状況（自分のものと同じような）の大きなデータセットでは、セットベースの操作よりも性能が劣る可能性があります。

バックしながら、私はこのAに見えた - いくつかの良い答え&コメントの人々はそれはあなたが上で作業しているものとのrelaventかもしれない投稿：When are TSQL Cursors the best or only option?