Effective management of data changes

Question

I have a table called Bookings. This table contains data representing a booking made for a particular service, with many variables.

A while ago I came across a problem w

Answer 1

From the answers you gathered already it's pretty apparent that whatever you do, it will require some or more redesign.

One of the solutions I don't see yet and that I've used in the past to solve such problems (i.e. orders that are changed) is to keep everything in the same table and use field(s) to differentiate them.

You can change the bookings table to add an incremented integer per booking (i.e. version_number) and a is_latest field. This way you can query with is_latest=true to get the current record and its version_number. If it is 0, there were no changes, if it is >0 then there are changes (that number will equal the number of changes). You will be able to "rewind" or "replay" the history if you go from latest version to 0 or the opposite way round and each time you'll be having a complete record that your app understands without modifications.

If is_latest is indexed the querying speed will (almost) equal the original table querying speed and of course you can add more booleans like is_original if you need to get the original booking many times.

This has the benefit that it will most probably require you to change only the Booking model but that will depend on your code.

EDIT: I believe that this approach will be most compatible with your requirement about reporting and financial record as you will always have the original record (version 0) easily available.

Answer 2

What if you used a backup table to store data from the original table before modifying the original table? you could then use a rollback function to restore data to a previous state.

Here is a flowchart of my database update process theroy: http://i1371.photobucket.com/albums/ag300/joshua127/BookingFlowchartinsert_zps5c2d55f8.png

Here is a flowchart of my selection process theroy: http://i1371.photobucket.com/albums/ag300/joshua127/BookingFlowchartselect_zps702fa902.png

Hope this helps, just another way to look at it.

P.S. To keep the financial information unchanged, you could write your update functions to count the number of columns to be updated (based on your update array of column names) and provide variables to hold specific values for those columns alone. you could reference the array indexes ($array['index']) in the SQL statement to make it dynamic.

Answer 3

It sounds like you're trying to implement a Temporal Database. Temporal support was one of the major additions to the ANSI/ISO SQL:2011 standard. MySQL (like most RDBMS) lags behind the standard. Think of Temporal Database as the DBMS equivalent of CVS/SVN/Git.

By contrast, the traditional database we use without temporal features can be called a Current Database.

In a Current Database, if you try to implement temporal support, you can fail in many ways with different approaches:

• The one-table approach. When you need to make modifications, you do UPDATEs on your original records, and unless you have some sort of homegrown trigger/audit logic, the history trail is absent. Even if you have an audit/change log, you'd have to do some ugly digging to reconstruct the change history.

• The two-table approach. Instead of making modifications in-place, you split out your data into two tables, one with the base/original records (e.g. booking), and another table for your changes/modifications/deltas. Then at least you have your original data preserved, but again you have to write complex logic to view the original data with modifications layered on. It gets even worse if you want only some of the modifications applied.

• The precalculated resultant table approach. You keep 3 or more tables: the base records, the modifications, and also a table which attempts to always have the resultant (keeps up to date the base + modifications). Good luck writing the triggers and procedures to do this calculation whenever you do INSERTs, and Heaven help you if an UPDATE or DELETE is needed. The setup is fragile and could break out of sync, such as deadlocks & rollback. If you don't do this within the DB with triggers/procedures, you could try to implement resultant calculation it in the application code, but have good luck at that -- and it could get ugly with multi-threaded consumers. And still, you don't have easy access to resultants with only some modifications applied.

Conclusion: If you're not limited to MySQL, you should really consider using a DB that has built-in temporal support. Otherwise, you're going to re-implement the wheel.

Answer 4

It seems to me, what you need is a kind of history of a table so that you are able to know what happen in the time.

I usually achieve such an approach by creating a parallel table called like the original appending _history to it. Bookings_history in your case. The structure would be similar to the original but prepending the columns:

a) timestamp, that save when the modification happened

b) id, to identify the row in the original table

A unique index on this two columns would be created.

Each time a modification happens, before applying the modification you copy the original row to the history table. Then you apply the modification on the original table. Doing so, the history table acts like a stack where you save snapshots of the original data.

I specially like this model because joining tables and applying search engines on the history table can be done in a similar way as you did for the original table, because the structure is quite similar. Also, if you want to know about modifications, you just need to compare rows of the history table.

I hope this helps.

Answer 5

Instead of applying the modifications to the original record, what if you did the reverse and applied the original record to the modifications? You could modify the modifications table (or a new table) to hold the original record with the modifications applied to it, and direct your searches there.

Another thought is that if the financial data is all that needs to be preserved, why not save it in another field or table and reference it when you need it? I agree that a re-design is probably the best/smartest approach for a long-term solution, but I figured I'd put my ideas on the table in case they can help.