【发布时间】：2010-10-16 08:09:48
【问题描述】：
我需要在数据库中插入年份（例如：1988 ,1990 等）。当我使用日期或日期时间时 数据类型，它显示错误。我应该使用哪种数据类型。
【问题讨论】：
-
这个问题肯定需要更多关于用例的信息。但很多时候时区很重要。 1990 年在澳大利亚比在美国更早开始。简单的 int 或字符串通常不是日期的正确选择。
标签： database types sqldatatypes
【发布时间】：2010-10-16 08:09:48
【问题描述】：
常规的 4 字节 INT 太大了，浪费空间！
你没有说你使用的是什么数据库，所以我不能推荐一个特定的数据类型。每个人都在说“使用整数”，但大多数数据库以 4 个字节存储整数，这远远超出了您的需要。您应该使用两字节整数（SQL Server 上的 smallint），这样可以更好地节省空间。
【讨论】：
-
通常情况下，使用 int 浪费空间比使用较小的数据类型更可取，因为大多数现代处理器比较小的数据类型更有效地处理 4 字节 int（32 位）。
-
@Ender，你并没有真正用这些值做数学运算，它更像是一个存储和查找过程。如果它们更小，您将能够在 ram 中存储更多值，如果它们更小，您将能够从磁盘读取更多值，等等。我找不到任何支持您想法的文章。 dba.stackexchange.com/q/4968
-
所有程序最后都编译成机器码，数字被加载到寄存器中。在现代 CPU 架构中，所有寄存器都是 32 位或 64 位的。因此，您的 RDBMS 系统必须将这些数字放入寄存器中，以便进行比较以满足查询中的条件。而对于tiny int和small int的情况，每次都要进行一次转换，比较耗时。您找不到支持我的观点或您的观点的官方文章，因为它通常是 CPU 和 IO 之间的权衡，因为使用 int 会增加索引大小并需要更多 IO
-
@ender，总会有取舍，我会针对 IO（和更小的数据类型）进行优化，因为 IO 通常是主要瓶颈。
-
@Weapon X，为什么要使用 4 个字节来存储一年？ char(4) 使用 4 个字节。我的回答建议使用两字节 int，它是 SQL Server 上的
smallint，可以存储范围内的值：-32,768 到 32,767，这足以存储一年。您希望使用尽可能少的空间，因为您可以修复每页更多的数据，和/或内存中的更多数据和/或内存中的更多索引等。如果我使用 smallint 而你使用 char(4)将使用两倍的空间/内存来存储相同的数据。数据库处理你的CHAR(4)比我的SMALLINT需要更长和更多的努力
如果您需要在数据库中存储一年，您可能希望使用 Integer 数据类型（如果您只存储年份）或 DateTime 数据类型（这将涉及存储基本上为 1 的日期/1/1990 00:00:00 格式）。
【讨论】：
-
不要偷懒，“只使用 int”。 适当调整数据类型的大小，两字节 int 是更好的选择。通过将 4 位数的年份存储在 4 个字节中，您浪费的资源不仅仅是磁盘空间。您的系统将永远承受使用两倍的高速缓存内存、推送两倍的 IO 数据量等这一列的负担。这很简单，请参阅：dba.stackexchange.com/q/4968
-
B-b-但是 32768 年的问题呢？ (j/k)
-
@KM。我同意这是一个应该进行的简单优化，但我们不要因为不这样做而过度劳累。并非每个项目都会看到任何显着差异。
-
@KM。我已经说过，“我同意这是一个应该做的简单优化”，所以我真的不知道你在争论什么。我碰巧在较小的临时系统上工作，这些系统永远不会从这种变化中看到任何好处。我也有 10 年的历史等系统。我们构建的内容是为临时使用（最多 6 个月）而设计的，即使在数据库不断增长的最坏情况/最佳情况下，也需要再过 10 年（至少）这样的优化才能使任何对我们来说有明显的不同。
嘿，你可以在 MySQL 中使用 year() 数据类型 它有两位数或四位数的格式。
注意：允许采用四位数格式的值：1901 到 2155。允许采用两位数格式的值：70 到 69，表示从 1970 年到 2069 年的年份
【讨论】：
在 MSSQL 中存储“年份”理想情况下取决于您使用它做什么以及该“年份”对您的应用程序和数据库的意义。话虽如此，这里有几件事要说明。 MSSQL 中截至 2012 年的年份没有“数据类型”。我倾向于使用 SMALLINT，因为它只有 2 个字节（节省了 INT 要求的 4 个字节中的 2 个）。您的限制是您的年份不能超过 32767（从 SQL Server 2008R2 开始）。我真的不认为 SQL 会成为一万年后选择的数据库，更不用说 32767 年了。您可以将 INT 视为 MSSQL 中的 Year() 函数确实将数据类型“DATE”转换为 INT。就像我说的，这取决于您从哪里获取数据以及数据的去向，但是 SMALLINT 应该没问题。 INT 将是矫枉过正...除非您有其他原因，例如我上面提到的原因，或者代码要求需要 INT 形式（例如与现有应用程序集成）。很可能 SMALLINT 应该没问题。
【讨论】：
仅仅一年，没有别的吗？ 为什么不使用简单的整数？
【讨论】：
-
嘿！你为什么要让事情变得如此简单？我们将用完 SO 问题！
如果您只需要存储年份，请使用整数。如果您认为在查询此列时会有基于日期的计算，您也可以使用 datetime
【讨论】：
存储可能只是问题的一部分。这个值将如何在查询中使用？
是要与其他日期时间数据类型进行比较，还是所有关联的行也都有数值？
您将如何处理需求的变化？您对用更短时间片替换年份的请求的反应有多容易？即现在他们想要按季度分解？
数字类型可以很容易地在日期时间查询中使用，方法是使用一个查找表来连接，其中包含开始和停止日期（1/1/X 到 12/31/x）等内容。
【讨论】：
我不认为使用整数或整数的任何子类型是一个好的选择。迟早您将不得不对其进行其他日期操作。同样在 2019 年，我们不必太担心空间问题。看看我们在 2000 年节省了 2 个字节的成本。
我建议使用年份 + 0101 转换为真实日期的日期。同样，如果您需要将一年中的一个月存储年 + 月 + 01 作为真实日期。
如果你这样做了，你以后就可以在上面正确地做“约会的东西”
【讨论】：
您尝试在数据库中插入年份，然后使用：type YEAR
【讨论】：