Home/ Questions/Q 7420851
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T08:18:39+00:00

I am designing a rostering application for a situation where the staff being rostered

  • 0

I am designing a rostering application for a situation where the staff being rostered may be deployed multiple times over the lifetime of the application.

My current model stores additional data fields in each deployment record.

In 90% of cases this data will not change during a deployment, but there will be some cases where it will. At the moment, I simply end the current deployment and create a new one with the relevant data updated.

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   |
------------------------------------------------------------

Example: Bob’s pay level is 3. He is first deployed in January 2011 at his regular pay level. His deployment ends in March 2011 (and therefore ceases to show on the roster from that date).

In July he is re-deployed, but this time at a higher pay level than his regular level.
In September his regular position is promoted to be in line with his deployment pay level (i.e. when his deployment finishes he will continue at level 5).

The July deployment finishes in December, but actually consists of two records.

I came up with this model to try and reduce the amount of date-period-join-grappling that I had to do, as well as to make it easy to update the interface if I need to add new deployment-specific fields.

It is extremely unlikely that the deployment table will grow much over a thousand records, as the application as a whole is designed for situations that are by their nature limited in duration.

My question: Am I shooting myself in the foot?

Is this an absolutely awful data structure? Should I bite the bullet and extract this data out into separate tables? Is there any way of doing this without multiplying the number of start/end date fields that I have to deal with any time I add a field?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I discovered a nice trick that you can play on your temporal tables: add a special column that I call continuity ID for lack of a better term. This column is equal to the primary key of the record that opens a group of related records representing the same item or action that you are modeling – in your case, a deployment. Let’s say the primary keys of the three rows in your example 1, 2, and 3. Then the continuity ID of the first record would be 1; the continuity IDs of the other two records would be 2, because they represent the same deployment, and the first record that belongs to the deployment they represent has the primary key of 2.

    With the continuity ID column in place, you can put additional fields into your temporal table, and be able to answer questions about what happened to your deployment relatively easily: given an ID of one of the records in the group (say, the most recent) you can easily query for the beginning and end dates, for the history of the item over time, for a state of the item as of a particular time, et cetera.

    • 0