4 ms·
Most order forms are snapshots of data at the instant of their lodgement, since they are sales contracts. It is a rookie blunder to link them relationally to ma
by inopinatus 5y ago
Most order forms are snapshots of data at the instant of their lodgement, since they are sales contracts. It is a rookie blunder to link them relationally to master data for products and PII &c.
The record of an order is not intrinsically PII and thereby subject to rights of erasure. It may well be equally unlawful in some jurisdictions to irrevocably destroy it entire, it being necessary for accounting or tax audit, or even simply for mundane followup process, such as returns, that arise from actionable consumer rights. Ergo, such documents must fundamentally survive the erasure/redaction of any PII it does include.
- jhgb 5y ago> It is a rookie blunder to link them relationally to master data for products and PII &c. Is it always? If that data is immutable, for example?
- snowwrestler 5y agoHow are you going to satisfy data compliance, which may require the deletion of PII upon request or expiration, if your PII data is immutable?
- atatatat 5y agoWas just considering this when I came across your comment. I'm hoping someone here can suggest a one-way audit-log audit-trail sort of solution, because I need this for the medical industry.
- deleted 5y ago[deleted]
- ranguna 5y agoI would say the structure of the records themselves can stay, but not the data itself. If you have a user table, maybe you can just randomly hash the sensitive user data but keep the record. Not 100% sure about this though, since you could probably derive the user with statistics like: if it's known that 1 person gets a specific disease every 10 years and you have an obfuscated record of a person connected with that disease, it's fairly straightforward to derive who that person is just through that connection.
- mvc 5y agoHow are you going to respond to a warranty claim if you've wrongly deleted the order data when a subject requests that you delete all PII you have about them? https://www.adyen.com/blog/gdpr-what-it-means-for-customer-payments-data https://www.adyen.com/blog/gdpr-what-it-means-for-customer-p...
- snowwrestler 5y agoYou store the sales contract separately, which is what this whole subthread is about. https://news.ycombinator.com/item?id=27251168 https://news.ycombinator.com/item?id=27251168
- jokull 5y agoThe way to do it is to have foreign keys, but instead of hard delete you scrub data in the columns.
- snowwrestler 5y agoSeems like if you can scrub data, it is mutable? Maybe I misunderstand what “immutable” means.
- jhgb 5y agoI'm not sure how this changes anything. Is your PII in the order forms/sales contracts mentioned above? If yes, you'll have to delete those as well anyway, right? If it's not, the order forms/sales contracts themselves don't have to be linked to something that may potentially get deleted. Please note that by "immutable" I don't mean that data won't get deleted eventually, just that it won't be deleted until nothing needs it anymore (and until then won't be mutated either), so basically the same thing that languages like Haskell mean by "immutable". Then, once you don't need it (= it's not observable anymore), it could perhaps get archived or erased, whatever you prefer.
- inopinatus 5y agoThen it isn’t master data anymore; it’s just one field of a record of a commercial document. This is taking a long way around to the same point. (Presumably no-one is trying to reference-count GC their RDBMS. If so, I wish them all the luck in the world.)
- jhgb 5y agoI'm not quite sure what "master data" means in English (a non-native language to me) but Wikipedia tells me that it's "data about the business entities that provide context for business transactions" (and lists examples that sound relevant for this situation to me). Based on that I'm inclined to think that this would qualify.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]