|
|
|
|
|
|
by golover721
2238 days ago
|
|
|
This gives me nightmares about having to retrofit GDPR requirements into a complicated system with many data stores and applications. Not only the difficulty of ensuring data is deleted but tracking data lineage so you can delete derived data too. Fun times! |
|
|
This is true when the domain is not well defined, that is the case for many legacy systems. Usually this systems have also problems with de-normalized data where there is several copies of the same entity across the system. Copies get out of sync.
I do not think that nowadays is as common as it used to be. When I was a kid, I saw many systems where you had "customer" data that was replicated in the two or three applications that were using it. Then, maybe at night, some task will "make sure" that all the data was on sync or in real-time with triggers in the database. Applications that were not part of this synchronization will pop up, some fields will be in one application but not in another one, etc. Bad-defined domain objects and identifiers will make sometimes fields too small to fit the original data, being in the wrong format (text vs numeric) or miss unique keys and duplicate rows.
Q: "Can you send a mail (stamp-based-mail) to everybody that works the Christmas shift?" A: "No. That data is in the scheduling system. We can only send mails from the Human Resources system as is the only one that stores the address".
I hope new generations of developers do not find themselves in this situations, but they will need to maintain the many legacy systems that still live way beyond what anyone expected.