私はパーティーに超遅れていますが、これは既存の回答のいずれにも表示されません。
GROUP BY DATEADD(MINUTE, DATEDIFF(MINUTE, '2000', date_column) / 10 * 10, '2000')
- 用語は、任意の数に変更することができ、それぞれ。
10
MINUTE
DATEPART
- これは
DATETIME
値です。つまり
、
- 長い時間間隔で正常に動作します。(年の間に衝突はありません。)
SELECT
ステートメントにそれを含めると、指定したレベルで切り捨てられたかなりの出力を持つ列が出力されます。
'2000'
SQLが日付計算を実行する「アンカー日付」です。Jereonh は、最近の日付を秒またはミリ秒でグループ化すると、以前のアンカー()で整数オーバーフローが発生することを以下で発見しました0
。†
SELECT DATEADD(MINUTE, DATEDIFF(MINUTE, '2000', aa.[date]) / 10 * 10, '2000')
AS [date_truncated],
COUNT(*) AS [records_in_interval],
AVG(aa.[value]) AS [average_value]
FROM [friib].[dbo].[archive_analog] AS aa
GROUP BY DATEADD(MINUTE, DATEDIFF(MINUTE, '2000', aa.[date]) / 10 * 10, '2000')
ORDER BY [date_truncated]
あなたのデータスパン世紀た場合は、‡ 2次またはミリ秒グループ化するための単一のアンカーの日付を使用すると、まだオーバーフローが発生します。それが発生している場合は、各行にビニング比較を独自の日付の午前0時に固定するよう依頼できます。
上に表示されている場所ではDATEADD(DAY, DATEDIFF(DAY, 0, aa.[date]), 0)
なく、代わりに使用してください'2000'
。クエリは完全に読めなくなりますが、機能します。
代替CONVERT(DATETIME, CONVERT(DATE, aa.[date]))
として、代替品があります。
† 2 32 ≈4.29E + 9、ので、あなたの場合DATEPART
、IS SECOND
、あなたはどちらかの側に43億秒を取得、または「アンカー±136年。」同様に、2 32ミリ秒は≈49.7日です。
‡あなたのデータが実際に何世紀または千年にまたがり、ある場合には、まだ二またはミリ秒...お祝いに正確な!何をしていても、続けてください。
ROUND((DATEPART(MINUTE, DT.[Date]) / 5),0,1) * 5
ので、データを見ると、最も近いタイムスロットと相関しています