I have run into an interesting problem. I have inherited a database for daemon process that polls and accepts reports from remote embedded systems. Each site that has one of these systems can monitor over a dozen different fuel tanks. (In practice, most monitor 2, 3 or 4 tanks.)
When something happens, such as a tank being refilled or a tank reaching a minimum level, the program saved that event in a Postgres database. The way the database was originally constructed, it was saving all the information from each fuel tank (type of fuel, etc.) in the event record, even though there was a separate “tanks” table. I added a foreign key field to the table to associate it with a particular embedded unit, and a foreign key to the events table to associate it with a particular tank.
Now here’s the problem: tanks can be added, removed, or have the type of fuel they store changed at any time. Adding tanks shouldn’t be a problem, but if one is removed, those event recorded would be “orphaned”. Worse if the type of fuel is changed, from say “jet” to “rocket”, then when someone searches through the history, they would think all those old events happened to the “rocket” fuel, when in fact they happened to the “jet” fuel.
I have received a couple of suggestions offline: (1) make a second, archive table of the tanks, and when anything changes, move that tank record, with its unique ID, to the archive table, and make a new record with new ID for the new state of the tank, or (2) and an “active” field to the tanks table, and still create new rows when specs change, but only flag the current state of the tanks as “active”.
Does anyone have any opinion on these proposed solutions, or another idea that might work?
Where’s the problem? All the relevant information is in the event record; or when you created the link between tank and event you didn’t persist the tank information? . The fact that it is orphaned isn’t a problem removing the fuel type from the event table is what caused the problem.
There are several reasons why to persist information forward. one of which is history. By linking the tables back to a tank entity is nice it shows you what IS current state. the event table shows you history if the “type” is different than the type on the tank table..
I guess I don’t understand the problem well enough:
Are users wanting to see all events even if a tank is deleted?
Would adding an associative table between tank and events for tank type with a start and end dates solve the problem?
What’s wrong with persisting some tank information to the event? This way you know the state of the tank at the point in time the event occurred?