命中计数器：单独的日期 + 时间字段与一个 DateTime2 字段答案

【问题标题】：Hit Counter: Separate Date + Time Fields vs one DateTime2 field命中计数器：单独的日期 + 时间字段与一个 DateTime2 字段
【发布时间】：2016-10-26 13:47:43
【问题描述】：

我正在计划一个点击计数器，并且我计划进行许多报告查询以显示一天、过去一周、过去一个月等的总点击数，以及一个将提供一个图表来显示在特定日期范围内，特定页面的哪个时间段最受欢迎。

考虑到这一点，将DATE 存储在与发生命中的TIME 不同的字段中，然后添加索引是否有益？对于其中一些查询，我将使用具有范围（大于 x 且小于 y）的where clause。我确实希望有关于 Date 和 Time 的查询，例如“在过去 6 个月内，显示一天中每小时分组的命中数。”

我是否过于复杂了？我应该只使用一个 DateTime2(0) 字段还是为此使用两个字段有一些优势？

【问题讨论】：

我会说去一个简单的日期时间。尽管为此保留两个单独的字段似乎很有用，但最终您将始终希望发生最多或最少点击的日期和时间范围。因为有像 DATEPART 这样的函数可以帮助轻松打破日期和时间，将日期和时间放在一列中会更有意义。
DateTime 适用于所有目的。对于一天中的特定时间，您可以像@Sam 提到的那样使用 DATEPART。要进一步分解（例如半小时的块），您可以使用 DATEDIFF(MINUTE, 0, DATE) % 1440 / 30 等时髦的东西将其分解为 48 个半小时的片段。
迄今为止，我还没有找到时间字段（在表格中）的有用用途，最好用作日期时间。我怀疑你太聪明了，你想多了。

标签： sql-server database-design relational-database hitcounter

【解决方案1】：

我认为您使用这种方法与premature optimization 接壤。

使用日期时间。在适当的时候（即在您的应用程序达到生产状态并且您对实际需求及其执行方式有了更好的了解之后），您可以例如引入视图以对您拥有的任何报告/查询更有用的方式来聚合您的数据经常执行。

在最极端的情况下，您甚至可以重构架构并将所有内容从 Datetime 迁移到两个不同的字段，但我怀疑这是否有必要。

【讨论】：

是的，我越想，它确实感觉像是过早的优化。感谢大家为我节省了一些不必要的麻烦。