The Dangers of Duplicate Data

Received an email from Amazon today, this email explaining that delivery of my parcel was delayed demonstrates the dangers of duplicate data, I think:

29/09/2016 is actually a Thursday!

29 September 2016 is actually a Thursday!

The duplication I am thinking of is that in addition to providing the date; 29/09/2016, they have also chosen to provide a refinement; ‘Friday’.

The problem here is date is actually a Thursday!

No doubt someone thought that while providing the date was specific, perhaps some people might like to see a day-of-week because; well, I guess we all have days when we know the day but not the date! But to have provided duplicate interpretations of the same data is is only helpful if it is correct!

I’d be fascinated to know how it came to be that they got this wrong in this particular email!


In this simple case, the bigger problem is that of extracting the day of the week from the date.  But in other senses you may see real-world examples not dissimilar to this.  In addition to ensuring the first conversion from one format to another is correct, if duplicate forms of the same data is persisted in a database you need to be really certain that any modifications to one field correctly update the ‘duplications’ in the other related fields.


Another thing you need to be sure about with providing your customers with information is that it is correct.  A few minutes after receipt of the email above, I got another email telling me that the parcel was delivered successfully!