オプション #1 : MS SQL SERVER 2008 を使用する
タイムスタンプで注文すると、rank()
関数と一時テーブルを使用できます。CTE とテーブル変数も使用できます。パフォーマンスは難しい部分なので、将来これが繰り返される場合は、3 つのオプションをテストすることをお勧めします。2 つの例を示します。
TEMPORARY TABLE ( SQLFiddle で試してください):
select rank() OVER (ORDER BY order_timestamp) as 'Rank', status into temp1 from temp
select t1.status as status, case when t1.status - t2.status = 0 then 'not changed' else 'changed' end as changed
from temp1 t1, temp1 t2
where t1.Rank = t2.Rank + 1
drop table temp1
CTE ( SQLFiddle で試してください):
with CTE_temp as (
select rank() OVER (ORDER BY order_timestamp) as 'Rank', *
from temp
)
select t1.status as status, case when t1.status - t2.status = 0 then 'not changed' else 'changed' end as changed
from CTE_temp t1, CTE_temp t2
where t1.Rank = t2.Rank + 1
オプション #2 : MS SQL SERVER 2012 を使用する
MS SQL SERVER 2012 の導入lead
およびlag
( http://blog.sqlauthority.com/2011/11/15/sql-server-introduction-to-lead-and-lag-analytic-functions-introduced-in-sql-server-2012 / )。
この場合、オプション #1 は引き続き有効ですが、@RomanPekar のソリューションを試すこともできます。
アップデート:
@RomanPekarのコメント(および誰かの反対票)に基づいて、特に大量のデータセットが予想される場合、一時テーブルはCTEおよびテーブル変数よりも完全に優れたパフォーマンスを発揮できると言わざるを得ません. オプティマイザーは、一時テーブルの統計を使用してクエリ プランを確立できます。これにより、パフォーマンスが向上する可能性があります。
同様に、OPが後でデータを提供したい用途に応じて(おそらくより多くのクエリ)、一時テーブルはまだそこにあり、新しいクエリを実行する必要はなく、インデックスを使用してパフォーマンスを向上させることができます。
ところで、私の答えをハッキングしてCTEまたはテーブル変数に変換するのは簡単なので、これが彼が将来繰り返す操作である場合、OPが3つのケースのパフォーマンスをテストすることをお勧めします。