时态数据库的日期应该存储在一个或两个表中吗？如果这不违反规范化？
PERSON1 DATE11 DATE21 INFO11 INFO21 DEPRECATED
PERSON2 DATE21 DATE22 INFO21 INFO22 CURRENT
PERSON1 DATE31 DATE32 INFO31 INFO32 CURRENT
DATE1 和 DATE2 列指示 INFO1 和 INFO2 在 DATE1 和 DATE2 之间的时间段内为真。如果 DATE < TODAY，则事实已被弃用，不应再在用户界面中显示，但不应出于历史目的而将其删除。例如，现在不推荐使用 INFO11 和 INFO21。
我应该拆分这张桌子吗？我应该将状态（已弃用或当前）存储在表中吗？
为了进一步澄清这个问题，Deprecated 是业务使用的术语，如果您更喜欢“不是当前”，问题不是语义，也不是关于 sql 查询，我只想知道哪种设计违反或最适合规范化规则（我知道标准化并不总是可行的方法，这也不是我的问题）。
“我想知道哪个设计违反了规范化规则”
取决于您要遵循的规范化规则集。
第一个也是最有可能违反规范形式的，在Date 的书中，它违反了first NF，是你在保存“当前”信息的行中的结束日期（抽象出未来信息的可能性）：你如果使该属性为空，则违反 1NF。
违反BCNF显然可能是您选择密钥的结果（因为在非时间数据库设计中也是如此 - 时间方面在这里没有区别）。Wrt“选择键”：如果您使用单独的开始日期和结束日期（并且 SQL 类型让您别无选择），那么您很可能应该声明两个键：一个包含开始日期，一个包含结束日期。
另一个设计问题是多个数据列。这个问题在“时态数据和关系模型”中进行了相当广泛的讨论：如果 INFO1 和 INFO2 可以相互独立地更改，最好将表分解为仅包含一个属性，以避免“如果您必须在每次行中的单个属性更改时创建一个新的完整行，则可能会发生这种情况。在这种情况下，您给出的设计违反了第六范式，如“时间数据和关系模型”中定义的（该范式）。
规范化是一个关系数据库概念——它不适用于时态数据库。这并不是说您不能将时态数据存储在关系数据库中。你绝对可以。
但是，如果您使用时态数据库设计，则适用时态规范化的概念而不是关系规范化。
您没有指出日期的含义。它们是指（a）所述事实在现实生活中真实的时期，还是（b）数据库持有者认为所述事实为真实的时期？如果（b），那么我永远不会这样做。更新完成后立即将更新的行移至存档表/日志。如果（a），那么下面的陈述是有问题的：
“事实已被弃用，不应再在用户界面中显示”
如果一个事实不再“需要出现在用户界面中”，那么它也不再需要在数据库中。保留这些事实只能实现一件事：降低所有其余部分的总体性能。
如果您确实需要这些历史事实陈述来满足您的要求，那么您所谓的“已弃用的事实”可能仍然与业务密切相关，因此根本没有“弃用”。假设由于这个原因，您的数据库中几乎没有“真正弃用”的事实，那么您的设计是好的。只需通过定期从操作数据库中删除它们来减少“真正弃用的事实”的数量。
(PS) 说你的设计好，不代表你不会遇到任何问题。SQL 非常不适合优雅地处理此类信息。“时间数据和关系模型”是对该主题的出色处理。另一本书，来自 Snodgrass 的书，也经常受到表扬，虽然不是我。那是一本关于用 SQL 处理这些问题的食谱的食谱，正如以下关于这本书的 SO 对话所证明的那样：
（问）“我为什么要读那个？” (A) “因为您要求的触发器在第 135 页。”