规范化这个 mysql DATE 列是否矫枉过正？答案

【问题标题】：Is normalizing this mysql DATE column overkill?规范化这个 mysql DATE 列是否矫枉过正？
【发布时间】：2015-03-25 09:00:18
【问题描述】：

我正在考虑忽略规范化规则以使表格更易于使用，我想知道这是否会导致任何重大问题或违反此类事情的最佳实践。

我正在存储月份范围的数据，并且month 列会有很多重复值。它将存储月份和年份，当天的垃圾值为 1，所以我会在下个月得到很多 '2015-03-01'，然后是很多 '2015-04-01'，等等...

这是我正在考虑的两个选项：

table `data`
------------
`id` INT
`data` VARCHAR
`month` DATE

或标准化，这将防止那些重复但感觉乏味，就像它实际上并没有帮助我

table `data`
-------------
`id` INT
`data` VARCHAR
`month_id` INT

table `month`
-----------
`id` INT
`month` DATE

在考虑这样的非规范化时，有什么好的指导方针可以遵循吗？

编辑：这是我的第一个场景的一些示例数据：

INSERT INTO data
(data, month)
VALUES
('sample1', '2014-11-01'),
('sample2', '2014-11-01'),
('sample3', '2014-11-01'),
('sample4', '2014-11-01'),
('sample5', '2014-12-01'),
('sample6', '2014-12-01'),
('sample7', '2014-12-01'),
('sample8', '2014-12-01'),
('sample9', '2014-12-01');

【问题讨论】：

您能否提供一些当前布局存储的示例数据，最好是 SQLFiddle？
不，我认为你不应该这样做（第二个）。当涉及按日期排序数据或搜索特定时间段的记录时，您希望能够直接在日期列上使用索引——必须先通过另一个表进行转换，效率会降低。此外，恕我直言，日期可以作为原子值。
sqlfiddle 现在不适合我，但我已经用第一个场景的插入语句修改了我的问题。
这是有道理的@CBroe
这与规范化无关。

标签： mysql normalization denormalization

【解决方案1】：

如果在您的第二个选项中，表月份仅包含 id 和月份，我将不得不说“那有什么意义？”。如果它包含有关月份的额外信息（例如，该月的工作日数），则值得对其进行规范化。

【讨论】：

我同意您的观点，即考虑我们是否要存储本月的任何元数据。我能想到的唯一一点是防止大量重复值。重复的价值观吓坏了我，让我觉得我做错了。它也会节省（可能可以忽略不计）的空间量，但我怀疑它实际上在性能方面效率较低。
如果性能是您的首要任务，我认为您需要进行基准测试以确保您采用正确的方法。如果您需要某种面向未来的验证，其中月表将来可能包含额外信息，那么值得拥有两个表。如果简单是关键，我觉得一张桌子就足够了。