Asp.net 使用日期和DATETIME时是否需要考虑性能或存储差异？

在使用SQL Server和ASP.NET时，使用

Date

与

DateTime

相比，是否有性能/存储方面的考虑因素

---

即使我不需要它，我也一直在使用

DateTime

处理大多数事情

DateTime每个值需要8个字节

日期是3个字节

我不能为低水平的表现说话；但是，一般来说，我们发现默认情况下将值存储为DateTime是一个错误。您迟早会遇到UTC问题，并且必须开始计算时间部分中有00:00:00.000的日期的偏移量

---

如果只是存储日期，我会坚持使用日期数据类型；每页可以容纳更多行，并为自己节省大量麻烦

取决于存储的行数以及使用它的目的。日期为3字节，日期时间为8字节。当您有几十亿行数据，或者正在将其用作索引时，可以快速添加数据。当然，存储的值的分辨率也存在差异。date和datetime之间也有其他日期类型，例如smalldatetime，它们更紧凑，同样具有不同的折衷

注意事项：

• 性能：日期类型的位数减少意味着每个sql页（数据页或索引页）的行数增加意味着执行查询时要读取的页数减少
• 兼容性：

  DATE

  类型是在SQL Server 2008中引入的，因此您的应用程序不再与SQL Server 2005兼容
• .NET:在.NET中没有

  Date

  类-

  Date

  转换为

  DateTime

  .NET类
• LINQ:LINQ2SQL（和SQL金属工具）与

  DATE

  SQL类型配合得很好
• 您可以从

  DATETIME

  doing

  CAST（@myDateTimeParam AS DATE）

根据我的经验：我喜欢这种新类型，并且在编写T-SQL或C时没有遇到任何问题#

请注意这一点（混合比较日期的数据类型）：

结果是：

Not in period!

在

BETWEEN

上，比较

@endDay

被强制转换为

DATETIME

（时间点；与

@eventTime

一起使用的常见类型），我猜-是什么给出了不直观的结果

与之相比：

DECLARE @startDay DATE = '2012-04-11' -- day
DECLARE @endDay DATE = '2012-04-13' -- day
DECLARE @eventTime DATE = '2012-04-13' -- day

IF @eventTime BETWEEN @startDay AND @endDay PRINT 'In period.' ELSE PRINT 'Not in period!'

结果:

In period.

In period.

有了它：

DECLARE @startDay DATETIME = '2012-04-11' -- day, but point in time in fact 00:00.000
DECLARE @endDay DATETIME = '2012-04-13' -- day, but point in time in fact 00:00.000
DECLARE @eventTime DATETIME = '2012-04-13' -- day, but point in time in fact 00:00.000

IF @eventTime BETWEEN @startDay AND @endDay PRINT 'In period.' ELSE PRINT 'Not in period!'

结果:

In period.

In period.

---

这还取决于“日期”的上下文是什么，以及是否需要注意（我的星期五可能不是你的星期五）。并不是说将所有内容存储为UTC更好。。。因为它仍然不能捕捉到TZ本身。还有一个

DATETIMEOFFSET

类型；但是，我不知道它如何映射到.NET:（@Click Rex）你能解释一下你的上下文吗？DateTime只是“本地时间”-它没有时区表示的概念。这意味着你必须知道它是用什么时区编写的，以使你能够准确地解码它。还有一系列的问题，比如夏令时埋在那里。这就是关于UTC的评论的来源-所有应用程序都会将日期烹调到UTC中存储，并返回到本地时间进行显示是的。听起来很简单？不是很简单-实际上，要让所有的应用程序都做到这一点，而不需要经过大量的刻意努力和测试。DateTimeOffset类型的引入是为了尝试缓解这个问题。@PankajGarg这是你所说的一切…我总是选择UTC。在使用DateTime时，这是最不坏的方法，IMOHO。（与实际存储TZ/偏移量不同，这可能只是一个需要处理的PITA。）是的，我同意pst，我们也使用UTC。在引入偏移量概念时，他们所做的只是将UTC转换的问题改为在所有日期/时间编码中添加时区。