日付と時刻を別々の列に保持する理由はありますか？

日付と時刻を別々の列に保持するというソフトウェアベンダーの決定を理解しようとしています。たとえば、行が作成または更新されたとき。時間と日付はどちらもDateTime列です。SQL Server 2005を使用しています。

データベースにはERPシステムのデータが保持されており、最大のテーブルには約300万行が含まれていると思います。ほとんどのテーブルは、おおよそ100 000〜1 000 000行です。

私は個人的にはデフォルトで、単一のタイムスタンプに対して単一のDateTimeを選択します。これにより、時間差の計算が容易になり、日付と時刻の部分をタイムスタンプから簡単に抽出できます。また、使用するスペースも少なくなります。

日付と時刻を分離することは悪い習慣なのでしょうか、それともこのデザインに理解できない非常に素晴らしいものがあるのでしょうか？

私の推測では、これはレガシーサポートであると考えられます（つまり、ソフトウェアのバージョン1に戻り、日付と時刻が別々のフィールドにあり、常にそのように機能していたため、サポートを強制されていました）。

とはいえ、日付と時刻を区切ることについて見事なことは何もないので、見落としはありません。

（他のオプションは、ERPシステム開発者が日時フィールドに日付と時刻を格納できることを知らなかったということですが、以前のバージョンと同じように機能させるためのビジネス要件があった可能性がはるかに高いです。）

一般的には使用方法により異なります。多くのクエリがサブ要素を結合している場合は、代わりにそれらを一緒に格納することを検討してから、まれにそれらを分割する必要があるというオーバーヘッドを引き受けます。もちろん、分割は時々より複雑（または不可能）です。person_full_name抽出する必要がある属性を検討してくださいperson_family_name。とは言っても、一時的な値のダウンキャストは簡単なので、通常は日付と時刻を一緒に格納することをお勧めします。

また、制約（およびおそらくトリガー）を使用して、両方を一緒に、かつ別々に格納することを検討してください。これらが同期しないことを確認します。これにより、データ。

運用システムでこれを使用することはあまりありません。分析システムでは、「日」の粒度を持つ個別の日付ディメンションが必要になる場合があるため、日付は日付のレポートロールアップにリンクし、何らかの理由で時刻による分析を行う場合は「時間」列が必要になる場合があります。 。

コアの日時列に基づいて計算された列として日付と時刻を提示することもできます。

ConcernedOfTunbridgeWeのコメントに追加すると、DateDimensionテーブルとTimeDimensionテーブルがある場合、クエリのパフォーマンスが向上します。ファクトテーブルにdateDimensionKeyとTimeDimensionKeyの両方があるとします。午前8時から午後5時の間に何かの数を見つけたい場合は、簡単に行うことができます

SELECT COUNT(1) FROM FactTable f Inner Join TimeDimension t on f.TimeDimensionKey = t.TimeDimension WHERE t.Hour BETWEEN 8 AND 17.

TimeDimensionKeyにインデックスを追加した場合、データを検索するには、ファクトテーブルの結果のインデックスシークのみが必要です。

TimeDimensionテーブルがない場合は、次のようなことを行う必要があります。

SELECT COUNT(1) FROM FactTable f WHERE DatePart(mintue, f.Date) BETWEEN 8 AND 17

データベースエンジンは、どのデータが返されるかを把握する前に、すべての行の結果を計算する必要があるため、おそらくテーブルスキャンが必要になります。