5

What's the best practice approach to storing historical records?

I have an entity whose rows will constantly get updated. I need to keep track of each row's history. There will be about 40K "current" records at any given time and each of them will be updated on a daily basis for about 60 days, then the updates will stop.

I see two options here:

  1. All current and historical records in one table - since each row will have an id that will allow me to identify which records are part of the same group.

  2. Current and historical records in separate tables - each time the current record is updated, a copy of it pre-update is put into the history table. The history table would have a FK.

Is there another option I haven't considered? Which option is the more appropriate approach to what I am trying to do?

DatabaseNewbie
  • 205
  • 4
  • 14

2 Answers2

1

There are some Open Source Change Data Capture tools that support MySQL you can find some of them in this answer: Does MySQL have a version of Change Data Capture?

I would personally recommend option #2 if you choose to deal with it yourself. A few simple triggers can automatically copy the new/modified rows into the other table and you can add a few columns in the history table to help track what is going on without having to touch any of the queries that use the primary table. This solution is extensible and is easy to deal with from a querying point of view.

Community
  • 1
Duffy
  • 1,054
  • 5
  • 7
1

There is a third option which is a combination of the two you've already thought of. You could keep current records in one table and all records in another table (current and historical).

In this approach, you can pick which table to read based on which type of question you have. If you only care about current values go to the current table. If you care about history, presumably your interest in history includes current values. Therefore you have "one stop shopping" for whatever you view you need for each circumstance.

Joel Brown
  • 12,529
  • 2
  • 31
  • 45
  • 1
    And you can use TRIGGERs on Current to add to Historical. – Rick James Mar 09 '16 at 01:20
  • "current and historical" is something that didn't occur to me. Right now, I'm having to do a UNION to get current and historical. Is that generally a bad idea? – DatabaseNewbie Mar 11 '16 at 00:31
  • @DatabaseNewbie - This is a trade-off. UNION is more expensive (in CPU cycles and code complexity) than a select from a single table. However, repeating current data in both the current and historical tables is more expensive (in hard disk) than keeping them separate. Where is your sensitivity and how would you strike this balance? I prefer simpler code which is more responsive. That's my bias. What is yours? (i.e. you have to decide based on your circumstances) – Joel Brown Mar 11 '16 at 02:04