Hacker News Reader

Comment by albert_e | Hacker News Reader

You recreated a production database of 20 years data by hand overnight?

You deserve an award !!!

Yep, the entire table. I figured since I had to write it to do the day at a minimum, doing the whole table would help me find corner cases and errors since it was a much larger range of data

Only that day's data was added on top of backup from last night...

he only recreated the ones not saved by the nightly backup, meaning he used the previous nightly backup and recreated from invoices the last ~23 hours.

No, I did the entire table. That helped me find corner cases and errors in my logic having such a bigger range of source data.

Wow,

I'd still not touch previous data.

I'd use it just for ensuring correctness, but I'd not touch it

Maybe I don't fully comprehend what you're saying... but is it even possible to do this?

I mean what if at some point particular entries were manually tweaked and the database was updated to fix an error in an invoice or something. And then you recreated data from what you assume is 100% reliable data.

I'm happy to try to understand if you don't mind simplifying the explanation.

Probably compared their code's recreated table against the table from the day old backup.

If twenty years worth of data (up until two days ago) match, then the recreation of the missing day is probably fine too. It's not guaranteed of course, but...

I can't remember the specific details now (almost 20 years have passed!), but the STKM table was effectively a performance/convenience data store. Every bit of information was available from other transactional data, but in order to actually have a chronological historical view of "stock movements", it was maintained in this central table.

Where did you get the 20 year old data from in that case? Actual paper in drawers, a directory of all invoices on disk, or some other database?

Reply on news.ycombinator.com