使用 SQL Server 2008 日期数据类型存储年份答案

【问题标题】：Using SQL Server 2008 Date Data Type to Store Year使用 SQL Server 2008 日期数据类型存储年份
【发布时间】：2009-10-23 19:25:42
【问题描述】：

在 SQL 2008 的新 Date SQL 类型中只存储一年是否有意义？我的老板想要这个，但我们提示客户在网络表单中输入可选的年份......只有 4 个整数。我不明白为什么我们要使用 Date 数据类型，因为它还包括日和月，而且我已经将它们分离到我们的 DB 表中的 int 字段中。

在我们的 Web 表单中，年份是可选的，因此如果他们只输入月份和日期，我将其存储在日期类型的字段中是没有意义的，因为年份必须是随意的。我想如果他们不输入年份，我们可以做 01-16-1900，然后我们只有一天和一个月..但无论如何，对我来说这是一个黑客。我宁愿将所有 3 个单独的字段分成单独的字段，因为我们将其中一个值（年份）作为可选值。我认为我们永远不会要求年份，因为它是用于生日，而且我们已经讨论过，如果我们仍然要求年份，那会惹恼客户。

【问题讨论】：

这取决于你要对数据做什么。为什么需要这些数据？一旦被捕获，你会如何处理它？

标签： c# sql-server-2008

【解决方案1】：

不，这没有任何意义。这将导致数据库中有更多空间，并且还会在您正在查找年份的地方添加不必要的任何代码。您必须在每个查询中使用 DatePart() 或在代码中提取年份。这两种方法都会损害性能。

但是，如果您的老板让您这样做，那么您可能应该这样做。我不会把它当成问题。你老板的理由是什么？

更正

我收回上面答案中“数据库中有更多空间”的部分。我所指的性能节省是按年转换为查询。

【讨论】：

他喜欢捷径，我不喜欢。他喜欢尽可能地结合事物，对我来说这是不好的做法。你不应该自动训练你的大脑来做到这一点。这就是为什么我们有包含 1000 多行代码的类的原因，因为他倾向于将所有内容结合起来，他认为 speration 是相反的……浪费时间。因此，现在我必须处理大量代码。所以对我来说，我非常仔细地考虑合并或分离事物。它让一切变得不同。任何关心干净代码的开发人员都会同意。 OOP 并不意味着要组合成一个女巫酿造，数据也不是
你错了，Date 类型是 3 个字节，而 3 个 int 字段是 12。使用 date 类型肯定不会影响性能。
冒着听起来好斗和幼稚的风险......不，你错了。（至少部分地）每次你只需要一年的时间，你都会失去转换的表现。您认为在具有数百万行的表中哪个会更快.. Select... Where DatePart(year, SomeDateField) = 2009 或 Select... Where SomIntField = 2009？转换很昂贵。这就是为什么我在我的回答中特别包含了“你必须在每个查询中使用 DatePart() ”这句话。
但是您对字段的大小是正确的。我站在那里纠正。
你是否会注意到调用 Year 的性能差异是有争议的，但我投票支持你纠正你的答案。

【解决方案2】：

不要想太多。只需使用 Date 类型并完成它。

注意：

考虑到 Ron 的回答，单独存储每个日期组件是时间上的倒退。你真的应该总是利用给你的工具。 Date 类型是任何 .NET 语言中的一等公民。

如果您没有考虑到，使用日期将节省空间。

http://msdn.microsoft.com/en-us/library/bb675168.aspx

【讨论】：

这不是想太多。我已经实现了整数字段，其中 3 个。当您可以将其分离到自己的 int 字段中时，为什么还要在一年中进行破解。年份是可选的。
他还将日期和月份存储为整数。我不认为需要投反对票。

【解决方案3】：

如果没有理由将单独的日/月 int 列放入 Date 列，我不明白为什么应该将可选年份存储为日期。

有些东西让我也想将月/日列视为日期...但我也喜欢“不要想太多”的其他逻辑...

【讨论】：

为什么？那么你必须在日期中填写虚假信息。这是我不想做的事情。为什么我要使用部分数据创建日期...没有意义。

【解决方案4】：

我个人会将所有 3 个值（月、日、年）作为日期存储在日期字段中 - 如果他们不输入，则默认为年份。这样你就可以自动验证有效的月份和日期......除了 2 月 29 日和没有年份，因为日期数学不会知道它是否是闰年。

将它们存储为整数意味着您必须自己进行所有验证。

【讨论】：