さて、今週と先週の比較を行うレポートを作成しました。お客様は、データが「ファンキー」であることに気付きました。さらに調査したところ、ISO規格に従って数週間正しく行われていないことがわかりました。このスクリプトをテストケースとして実行しました。
SET DATEFIRST 1
SELECT DATEPART(WEEK, '3/26/13')
, DATEPART(WEEK, '3/27/12')
, DATEPART(WEEK, '3/20/12')
, DATEPART(WEEK, '1/2/12')
SELECT DATEPART(ISO_WEEK, '3/26/13')
, DATEPART(ISO_WEEK, '3/27/12')
, DATEPART(ISO_WEEK, '3/20/12')
, DATEPART(ISO_WEEK, '1/2/12')
実行すると、これらの結果が得られました。
これは奇妙なことだと思ったので、さらに掘り下げてみたところ、SQL Serverは1月1日を年の最初の週としてカウントし、ISOは1月の最初の日曜日を年の最初の週としてカウントすることがわかりました。
その場合、問題は2つになります。質問1これはなぜですか?質問2はこれを変更する方法があるので、どこでもISO_Week
を使用するためにすべてのコードを変更する必要はありませんか?
SQL Serverが最初にWEEK
日付/部分を実装したとき、彼らは選択をしなければなりませんでした。当時最も一般的な標準に合わせる以外は、それほど意識が高かったとは思いません。これは、標準への準拠が最優先事項ではなかったときであることを覚えておいてください(それ以外には、 timestamp
、IDENTITY
およびTOP
)。彼らは後でISO_WEEK
(2008年と思います)を追加しました。それは、当面の回避策は、独自の低速でおかしなスカラーUDFを作成することでした。私の知る限りでは削除されました)。
DATEPART(WEEK
がDATEPART(ISO_WEEK
のふりをする方法がわかりません-コードを変更する必要があると思います(ソース管理を使用している場合、これはそれほど難しくありません-この計算を実行している場所はいくつありますか?コードをいじる必要がないようにどこかで計算することを考えましたか?今コードを変更しているので、これを検討するときかもしれません...) 。
そして、本当にwhy?への回答が必要な場合は、元の開発者を何人か集めて、彼らがデフォルトを選択した理由を判断する必要があると思います。繰り返しますが、これは実際の「F基準」ではなかったと思います。選択ではなく、「どのような基準ですか?」
ここに役立つかもしれないいくつかの情報があります:
http://blogs.lessthandot.com/index.php/DataMgmt/DataDesign/iso-week-in-sql-server
年の最初の週にさまざまな条件を想定している当局がいくつかあります。週の最初の日が最初の週から始まると想定する人もいますが、最も一般的な考え方は、最初の木曜日がある最初の週がその年の最初の週であるというものです。
そう ISO_WEEK
はそれを受け入れ、2010、2011、または2012で同様に確認できますISO_WEEK
は、1月1日が52週目または53週目であることを示し、WEEK
またはWK
またはWW
は最初の週であることを示しています。
SELECT DATEPART (WW,'01/01/2010') --> 1
SELECT DATEPART (WK,'01/01/2010') --> 1
SELECT DATEPART (WEEK,'01/01/2010') --> 1
SELECT DATEPART (ISO_WEEK,'01/01/2010') --> 53