Database 我应该规范化时态表中的额外字段吗？

我正在设计一个排班应用程序，用于在应用程序的生命周期内，排班的员工可能会被部署多次

我的当前模型在每个部署记录中存储其他数据字段

在90%的情况下，此数据在部署期间不会更改，但在某些情况下会更改。目前，我只需结束当前的部署，并创建一个更新了相关数据的新部署

Staff Table
-----------------------------
| ID | First Name | Surname |
-----------------------------
| 1  | Bob        | Brown   | 
-----------------------------
Deployments Table
------------------------------------------------------------
| Sta | End | Staff_ID | Reg Pay | Temp Pay | Other Fields |
------------------------------------------------------------
| Jan | Mar | 1        | 3       | 3        | Other data   |
| Jul | Sep | 1        | 3       | 5        | Other data   |
| Sep | Dec | 1        | 5       | 5        | Other data   |
------------------------------------------------------------

鲍勃的工资水平是3。2011年1月，他首次以正常薪酬水平被部署。他的部署将于2011年3月结束（因此从该日起不再出现在名册上）

7月，他被重新部署，但这次的薪酬水平高于正常水平。
9月，其常规职位将晋升至与其部署薪酬水平一致的水平（即，当其部署完成后，他将继续保持5级）

7月份的部署在12月份完成，但实际上包括两项记录

我提出这个模型是为了尝试减少我必须进行的日期周期连接抓斗，并且在需要添加新的部署特定字段时，可以轻松地更新接口

部署表的增长不太可能超过1000条记录，因为应用程序作为一个整体是为那些本质上受持续时间限制的情况而设计的

我的问题：我是不是在射自己的脚？

---

这是一个绝对糟糕的数据结构吗？我是否应该咬紧牙关，将这些数据提取到单独的表中？有没有办法在不增加每次添加字段时必须处理的开始/结束日期字段的数量的情况下做到这一点？

我发现了一个可以在时态表上玩的好把戏：添加一个特殊列，我称之为continuity ID，因为没有更好的术语。此列等于打开一组相关记录的记录的主键，这些记录表示您正在建模的同一项或操作（在您的示例中为部署）。假设示例1、2和3中三行的主键。那么第一条记录的连续性ID将是1；其他两条记录的连续性ID为2，因为它们表示相同的部署，并且属于它们所表示的部署的第一条记录的主键为2

---

有了continuity ID列，您可以将其他字段放入时态表中，并且能够相对轻松地回答有关部署情况的问题：给定组中某个记录的ID（例如，最近的记录），您可以轻松地查询开始日期和结束日期，查看项目随时间的历史记录，查看项目在特定时间的状态等。

谢谢您的提示。我想这会让生活更轻松一些。