我有一个Salary
带有 column的 table 和一个带有columnPersonalId
的 table 。Person
Name
在第一个表中,工资数据将保存在与表PersonalId
相关的Person
表中。在工资单中,所有数据将聚集在一起,Person
名称将从Person
表中引用。
1 年后,特定人名将从Michael
变为Maic
。现在我希望去年的工资单保留以前的人名Michael
,新的工资单由新名称生成Maic
。
我们怎么能做到这一点?
我有一个Salary
带有 column的 table 和一个带有columnPersonalId
的 table 。Person
Name
在第一个表中,工资数据将保存在与表PersonalId
相关的Person
表中。在工资单中,所有数据将聚集在一起,Person
名称将从Person
表中引用。
1 年后,特定人名将从Michael
变为Maic
。现在我希望去年的工资单保留以前的人名Michael
,新的工资单由新名称生成Maic
。
我们怎么能做到这一点?
这可能取决于您最需要进行的操作类型以及更改姓名的人数,因为您可能需要进行的连接数量可能会有很大差异。
这可能取决于您遵循的规范化规则,目前我没有考虑这一点。
无论如何,对于第一种情况,您不需要更改Salary
,但要重建 a 的身份,Person
您需要多个请求或至少一个存储过程。
在第二种情况下,您仍然不需要更改Salary
,因为您添加了一个字段Person
,但是要获取Salary
该物理人的所有条目,您需要做一些工作,同样可能是一个存储过程来获取添加的字段,然后是加入所有Salary
条目。
第三种可能是最简单的,但也是有限的,您需要在Salary
另一个字段中告诉要在该条目中使用的名称的索引。
最后一种情况为您提供了一个稳定的身份,但由于添加了表,它可能需要一些工作,并且仍然有多个实现。您可以使用该表而不是 来引用该表Person
,或者仅当您需要所有数据时才可以查阅该表,但您不能引用其主键,Salary
因为它不允许区分名称。
Lunadir 在某些方面是正确的——但所有这些方法都很复杂,而且难度很大。
另一种方法 - 更简单,也许更正确和健壮 - 是在 Salary 或 SalaryPaid 中保留 NAME 和 PAID_DATE 列,并写下付款时支付的实际姓名和日期。
良好的旧批处理风格——它的好处是实际捕获关键的财务事实、支付的金额和支付的名称,这是实际的可审计交易历史。
您是单独支付每个薪水条目,还是成批支付(PaySlip 或 SalaryPaid)?将 NAME 列放在您记录实际付款和发生的时间戳的任何位置。