日付と時刻を別々のフィールドに分割することと、日時データ型を使用して日付を単一のフィールドに格納することの賛否両論は何ですか？
私のデータベースは非常に大きく、1日あたり2,000万行の速度で成長しています。重要なタイムスタンプデータがありますが、ほとんどのレポートは日付範囲と週単位または月単位の比較に基づいています。時間は結果セットに時々表示されますが、基準として使用されることはありません。このことを考えると、日付のインデックスだけでなく、日付時刻フィールドを組み合わせると、かなりのストレージ容量を節約できると思います。 selectでパフォーマンスが向上するかどうか、または2つのフィールドに分割することに不利な点があるかどうかはわかりません。
レポートの目的で、フィールドを日付と時刻に分割すると、いくつかの利点があります。実現できる可能性のあるいくつかの利点は次のとおりです。
週、月などに分類した日付参照テーブル（データウェアハウスの日付ディメンションとほぼ同じ）を作成できます。これは、日付をキーにして結合で使用できます。
時刻による分析は、別の時間フィールドを使用すると簡単です。時間を適切な粒度に丸め、参照テーブルを作成することもできます。
各リーフ行にはまだ（IIRC）6バイトのページ参照があるので、インデックスは少し狭くなるため、全体としてそれほど大きな節約にはなりません。
アプリケーションでは、日付参照テーブルから勝つ可能性があります（効率的なルックアップのために日付にクラスター化されたPKを作成します）。これはおそらく、大きなテーブルで週と月を非正規化するよりも効率的です。
インデックスのパフォーマンスは変化しないはずです。
ソートされた配列またはツリー構造（つまり、インデックス）で、「に等しいすべてのエントリ」を要求するには、範囲内の最初と最後のエントリの検索が必要です。「以上のすべてのエントリ」を要求する場合と同じです。真夜中、 "の真夜中よりも小さい。
興味深いのは、クエリでMONTH(datetimecol>)と他の一般的に使用される式のインデックスです。これにより、余分なスペースを交換したい場合は、インデックススキャンを使用して、一致する月のすべての行を見つけることができます。高いパフォーマンスのインデックス。
ストレージスペースの視点から、データテーブルのサイズと比較してそれが重要であるとは思えません。