是否有充分的理由将日期和时间保留在单独的列中？

我试图了解我们的软件供应商决定将日期和时间保留在单独的列中。例如，当行被创建或更新时。时间和日期都是DateTime列。我们正在使用SQL Server 2005。

该数据库保存着我们ERP系统的数据，我相信最大的表包含约300万行。大多数表大约在10万至1000万行之间。

我个人默认情况下会为单个时间戳选择一个DateTime。这样可以简化时差计算，并且可以轻松地从时间戳中提取日期和时间部分。它还将消耗更少的空间。

是将日期和时间分开是不好的做法，还是我不理解的设计中有什么很棒的东西？

我的猜测是，这是一个遗留的支持内容（即，在其软件的版本1中，他们在单独的字段中拥有日期和时间，并且由于它总是那样工作而被迫支持它）。

就是说，分隔日期和时间并没有什么特别的，所以您不会缺少任何东西。

（另一种选择是，您的ERP系统开发人员不知道datetime字段可以存储日期和时间，但更有可能是他们有使其与以前版本相同的业务要求。）

通常，这取决于用法。如果许多查询将子元素连接在一起，则应考虑将它们存储在一起，然后承担在那些罕见的情况下必须将它们分开的开销。当然，拆分有时会更复杂（或不可能）：考虑person_full_name需要从中提取的属性person_family_name。也就是说，向下转换时间值是微不足道的，因此我通常更喜欢将日期和时间存储在一起。

还应考虑使用约束（或触发器）将它们存储在一起并分开存储，以确保它们不会不同步：这样，您在更新时（而不是在查询时）承担拆分/合并的命中数据。

我在操作系统中看不到有太多用处。在分析系统中，您可能需要一个单独的日期维度，并带有“天”的格数，因此该日期链接到日期的报告汇总，如果出于某种原因要按时间进行分析，则可能需要一个“时间”列。

您还可以基于核心datetime列将日期和时间显示为计算列。

要添加到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

这可能需要进行表扫描，因为数据库引擎需要计算出每一行的结果，然后才能确定可以返回哪些数据。