Timeline for Approach to Handling Errors/DataCorrections in Aggregated Data
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 26, 2017 at 6:31 | history | tweeted | twitter.com/StackDBAs/status/923436792048766982 | ||
| Oct 20, 2017 at 18:38 | answer | added | Michael Green | timeline score: 2 | |
| Oct 20, 2017 at 18:25 | history | edited | Michael Green | CC BY-SA 3.0 |
added 3 characters in body
|
| Oct 20, 2017 at 13:24 | comment | added | Vladimir Baranov | We store monitoring data in a similar fashion aggregating by hour, day, month. We discarded weekly as not very useful. Main difference to you - we store original detailed non-aggregated data for at least 7 days. This detailed table has ~150M rows - not too much, 20M per day. If some monitoring data is delayed by less than 7 days, having original detailed data allows to easily and accurately recalculate all affected summaries. So, based on your expected timeframes for possible incorrect data, keep a buffer of original details. This buffer is your "undo" buffer . | |
| Oct 20, 2017 at 12:53 | review | Close votes | |||
| Oct 20, 2017 at 18:22 | |||||
| Oct 20, 2017 at 12:00 | review | First posts | |||
| Oct 20, 2017 at 12:34 | |||||
| Oct 20, 2017 at 11:57 | history | asked | Eoin Campbell | CC BY-SA 3.0 |