时态数据库的日期应该存储在一个表还是两个表中？如果这不违反规范化？
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 现已弃用。
我应该拆分这张表吗？我应该在表中存储状态(已弃用还是当前)？
为了进一步澄清问题，已弃用是业务使用的术语，如果您更喜欢“不是当前”，则问题不是语义，也不是关于 sql 查询，我只想知道哪个设计违反或最好适合规范化规则(我知道规范化并不总是可行的方法，这也不是我的问题)。
最佳答案
“我想知道哪个设计违反了规范化规则”
取决于您要遵循的规范化规则集。
第一个也是最有可能违反范式的，在Date's book这违反了first NF , 是保存“当前”信息的行中的结束日期(对 future 日期信息的可能性进行抽象):如果您使该属性可为空，则违反了 1NF。
违反BCNF由于您选择的键，这显然可能会发生(因为在非时态数据库设计中也是如此 - 时态方面在这里没有区别)。关于“键的选择”:如果您使用单独的开始日期和结束日期(并且 SQL 让您别无选择)，那么您很可能应该声明两个键:一个包含开始日期，一个包含结束日期。
另一个设计问题是多个数据列。这个问题在“时间数据和关系模型”中进行了相当大的讨论:如果 INFO1 和 INFO2 可以相互独立地改变，最好分解你的表以只包含一个属性，以避免“爆炸式增长” rows count”，否则，如果每次行中的一个属性发生更改时都必须创建一个新的完整行，则可能会发生这种情况。在这种情况下，您提供的设计违反了第六范式，正如(该范式)在“时间数据和关系模型”中定义的那样。
关于database - 时态数据库建模和规范化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1514858/