データベース設計/パフォーマンスの専門家のために、SQL Server DatetimeとIntキーのパフォーマンス
会計年度の財務データを追跡するデータベースがある場合は、XとYの間のPaymentDateのようなdaterangeタイプの検索を行う方がパフォーマンスが優れているか、より明確であるか、キーベースのテーブルに会計期間が定義され、支払テーブルに支払日付とそのキーを付けておくと、where句はFiscalPeriodID = Xとなります。
データセットが小さくても問題はありませんが、このデータが何百万行もあると仮定します。
私は日常的に何百万行もの倉庫を扱っており、わかりやすい日付キーを使用する方法があります。これはYYYYMMDDの形式です。だから、2008年のすべてを見つけるために、あなたは何だろう：
select
*
from
gl
where
postdate between 20080101 and 20081231
を、これは驚異的に高速であるインデックス付きの列で、でも10億行を越えて。これはまた、日付表を指しているので、曜日、月の名前、またはその結合での日付についてのその他の情報につきまとうことができます。
もちろん、これらの倉庫はSSASキューブ（OLAPデータベース）をサポートするように構築されているため、日付表は日付の次元になります。 datetimeよりintに参加する方がはるかに高速です。
大規模な財務データセットでやることは、「データキューブ」です。
これは、基本的に各期間に必要なレポートを作成するプロセスを指しています。これらの句を実行する必要はないため、その期間のデータを表示するだけです。
だから問題ではありません。しかし、それを格納し、長期的な報告のためにより効率的な履歴データベースを実装します。
私は、エントリに直接格納された日付を使用します。
smalldatetimeを使用できる場合は、整数と同じサイズです（両方とも4バイト）。また、datetime型のデータ型は整数型です。
smalldatetimeの最初の2バイトは、1900年1月1日以降に経過した日数のようなもので、2番目の2バイトは深夜から経過した秒数のようなものです。 （これは正確ではないかもしれませんが、ポイントを得ることができます）。したがって、これらのデータ型は非常に効率的です。
私はwhere節がsmalldatetimeフィールドに対して実行されても問題ないと思います。
は、実際の日時またはsmalldatetime型フィールドの日付部分が有効であるかを考え... 1月1900
1日からの日数を表す4バイトの整数。これは、実際の日時にキャストすることができます暗黙的に非常に高速です（これは8バイトのDateTime値の最初の4バイトと全く同じ値なので）
SQL Serverエンジンが暗黙的に変換するため、Where句は実際の日時値に対しても使用できます1つは他の人に戻って、もう一度戻る。
プラス、32ビット（4バイト）の整数のすべてのpossile値が内部SQL Serverのdatetimeデータ型のために有効な日時（ミッドナイト）である
HRMええ、今私はあなたが書いたものを取ることができることと研究それはかなり標準的な解決策、特にキューブの中にあるようです。 – Eric
「時間」部分はどうですか？もし私も時間を保存する必要がありますか？時間のために別のフィールドを使用し、それをintergerとして保存し、必要なときに変換を行うのは良いことですか？ – Mahmoodvcs
David Steinはそれについての記事を書いた。彼は、日付フィールドはSQL 2008でより良いパフォーマンスを持っていると言います。url：[http://www.made2mentor.com/2011/05/date-vs-integer-datatypes-as-primary-key-for-date-dimensions/] （http://www.made2mentor.com/2011/05/date-vs-integer-datatypes-as-primary-key-for-date-dimensions/） – Mahmoodvcs