我正在设计一个排班应用程序，以便在应用程序的整个生命周期内多次部署正在排队的员工。
我当前的模型在每个部署记录中存储其他数据字段。
在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 |
------------------------------------------------------------
示例：Bob的薪资水平为3.他于2011年1月以他的正常工资水平首次部署。他的部署于2011年3月结束（因此从那天起不再显示在名册上）。
7月他重新部署，但这次的薪水水平高于他的常规水平 9月，他的常规职位被提升为与他的部署薪资水平一致（即当他的部署完成时，他将继续在5级）。
7月部署在12月完成，但实际上包含两个记录。
我想出了这个模型，试图减少我必须做的日期 - 期间 - 连接 - 抓取的数量，以及如果我需要添加新的特定于部署的字段，可以轻松更新界面。
部署表极不可能增长超过一千条记录，因为整个应用程序是针对其性质有限的情况而设计的。
我的问题：我是否在脚下拍摄自己？
这是一个绝对糟糕的数据结构吗？我应该咬紧牙关并将这些数据提取到单独的表中吗？有没有办法在不添加我必须处理的开始/结束日期字段数量的情况下添加字段？
答案 0 :(得分：0)
我发现了一个很好的技巧，你可以在时态表上播放：添加一个我称之为连续性ID 的特殊列，因为缺少更好的术语。此列等于记录的主键，该记录打开一组相关记录，表示您正在建模的相同项目或操作 - 在您的示例中为部署。假设示例1,2和3中三行的主键。然后第一条记录的连续性ID为1;其他两条记录的连续性ID为2，因为它们代表相同的部署，属于它们所代表的部署的第一条记录的主键为2。
使用连续性ID列，您可以将其他字段放入时态表中，并且能够相对轻松地回答有关部署发生的问题：给定组中其中一个记录的ID（例如，最新的）您可以轻松查询开始日期和结束日期，项目历史记录，特定时间项目的状态等等。