You deserve an award !!!
I'd still not touch previous data.
I'd use it just for ensuring correctness, but I'd not touch it
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.
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...
> UPDATE and DELETE are perfectly valid actions even without a state
Some may call this a fun quirk :) but I'd call it a horrible mistake in the design of the system! It should have been conceptually obvious to the designer that an empty set of rows is a perfectly valid state and is fundamentally different from "no state".
It was obviously designed by someone who had not taken any courses in formal languages, compilers and algorithms.
It had a fun quirk, the final result would change depending on which names you used for your variables.
When the phd student guiding our lab session told me to not use underscores in my variable names, I thought i'd humor her just to show her it was a stupid suggestion. But she knew more than me.
I told her one, and she didn't recognize the part number, so she said she'd look at the distributor's website. I watched her go to google.com, type in the url, and then I "helpfully" interrupted to explain that the address bar was where urls went, and that google was for searching for other things. She proceeded to click the "view cached version" in the google results, and told me that distributor's website was down and this was her workaround.
I learned a lot from that job. Including when to keep my mouth shut!
Some of the early SAN disk arrays used to use an assembly like config interface with no sanity checks, type in the wrong command and you could wipe the whole array.
The company I worked for at the time had a blanket policy that any change had to be implemented by the vendor to shift liability for any mistakes.
A friend of mine worked for a company repairing transmissions on drilling platforms. To say it was a specialty shop is an understatement. However, they had been in business for 40 years. While not a computer system from the 60s, theirs was a custom written solution from the 80s running on a DOS 286 PC. It was stuck on the top shelf of a closet with a UPS. The developer had long been "permanently" unavailable for at least a decade, and they were too scared to loose the data in having it rebuilt. I asked how scared, and the answer was "it's the only computer in the building with a UPS". I'm laughing at the insanity just retelling the story
It had SQL like syntax for manipulating data, but it was interactive. So you would SELECT the rows from the table that you wanted, then those rows would be part of your state. You would then do UPDATE or DELETE without any kind of WHERE, because the state had your filter from the previous SELECT.
It has a fun quirk though - if your SELECT matched no rows, the state would be empty. So SELECT foo WHERE 1=2 would select nothing.
UPDATE and DELETE are perfectly valid actions even without a state...
Working late one night, I ran a SELECT STKM WHERE something that matched nothing, then before I realised I realised my state had no rows matched, I followed up with DELETE STKM.
Yep, the entire Stock Movements table four the last 20+ years of business were gone.
The nightly backup had not run, and I didn't want to lose an entire day of processing to roll back to the previous night.
I spent the entire night writing a program to recreate that data based on invoices, purchase orders, stocktake data, etc. I was able to recreate every record and got home about 9am. Lots of lessons learnt that night.