用于将来生效日期条目的数据库PK-FK设计？

如何解决用于将来生效日期条目的数据库PK-FK设计？

| 最终，我将把它转换成Hibernate / JPA设计。但是我想从纯粹的数据库角度开始。我们有各种表，其中包含未来有效日期的数据。取得一个具有以下伪定义的员工表： 雇员 ID INT AUTO_INCREMENT ...数据字段... 从DATE起生效 有效期至DATE employee_reviews ID INT AUTO_INCREMENT employee_id INT FK员工编号 很简单。但是，假设雇员A的ID为1，那么有效起始时间为2011年1月1日，有效目标时间为1/1/2099。该员工将来将要更换工作，理论上将创建一个新行，id = 2，有效起始= 2011年7月1日，有效至= 1/1/2099，并且有效ID = 1 \至2011年6月30日。但是现在，我的程序将不得不每晚检查与员工有FK关系的任何表，并更新这些FK以引用新近生效的员工条目。 我在纯SQL和Hibernate论坛中都看到过各种帖子，我应该有一个单独的employee_versions表，在该表中我将存储所有有效日期数据，从而导致下面的更新的伪定义： 雇员 ID INT AUTO_INCREMENT employee_versions ID INT AUTO_INCREMENT employee_id INT FK员工编号 ...数据字段... 从DATE起生效 有效期至DATE employee_reviews ID INT AUTO_INCREMENT employee_id INT FK员工编号 然后，要获取任何实际数据，必须从具有正确的employee_id和日期范围的employee_versions中进行实际选择。对于每个版本化的实体都具有此辅助“版本”表，这感觉很不自然。 有人对您以前的工作有任何意见或建议吗？就像我说的那样，我首先纯粹从一般的SQL设计角度出发，然后再在Hibernate中分层。谢谢！     

解决方法

           该员工将在将来更换工作，从理论上讲，这将创建一个新的（员工）行 为什么？这有什么意义呢？您的“ 0”实体不再代表员工，而是代表“ absactact”概念的“职位上的人”。 我认为将员工“更换工作”时要更改的实体（职位）分离到单独的表中会更有意义，因此您不会遇到一个混乱的概念，即一个自然人实际上是多个人

employee

行。 我不明白为什么您认为必须从额外的表中进行选择似乎“不自然”-您会从具有单一性的员工（雇员的职位）中分离出具有多重性的职位（人的职位） ）。     ,        您需要确定是要设计数据库来支持操作还是要设计数据仓库来支持报告。如果是第二个，则您的设计一开始就与Kimbal的Type 2尺寸变化缓慢。传统上，您希望您的运营数据库代表员工的最新版本，并为其提供一些业务密钥（员工编号，SSN等）。然后可以将数据加载到数据仓库中，其中EMPLOYEE维度中的每个单独记录都将具有代理键和有效/结束日期。事实（例如评论）将基于业务密钥和日期/时间与EMPLOYEE维度中的记录相关。例如，您将能够区分雇员A担任初级技术员职位时的评论与他担任高级工程师职位时的评论。     ,        对于这种情况，我们通常有一个称为Active的布尔值字段，该字段使查询适用的最新记录更加容易。     ,        为了扩展matt b的答案，您对问题域的讨论使您很清楚，您的设计要求的是“位置”表。即使员工升职后，其评价仍然与该员工相关。而且，在我经历过的每家公司中，员工任期的概念都与他们在公司的整个历史有关，而不仅仅是当前的职位。 通常最好的做法是查看所需的任何复杂更新，以表明设计需要更改。     ,存在对应于独特人类的实体：

     EMPLOYEE
     eeid PK
     firstname
     surname
     dateofbirth
     dateofhire
     dateoftermination
     etc

并且存在与员工担任的职位相对应的实体：

     EMPLOYEEPOSITION
     id pk
     eeid FK references EMPLOYEE(eeid)
     title
     reportsto FK references EMPLOYEE(eeid)
     startdate not null usually
     enddate allows null

创建多个EMPLOYEE记录通常不会解决如何强制EMPLOYEE的职位可以重叠的问题。插入/更新到EMPLOYEEPOSITION通常会查看每个EE职位的开始日期/结束日期列，并根据有效的规则（例如，允许/禁止的重叠）来提交或回滚该操作。 可以使用eeid找到所有EE \的职位。 除非有必要，否则通常不会在EE记录中添加终止日期。如果EE是合同工，则我会将合同期限实例化为EMPLOYEEPOSITION。 您可以从此处为存在于多对一关系中的任何实体回溯到EMPLOYEE进行类比。     ,        查找时态数据库。尽管日期可能是将来的日期，但您的数据是临时的。大概您现在插入的面向未来的数据在将来的更改生效时仍将具有相同的形式和含义。