3 ms·
I think that this is one of those spots where, if you want things to be ORM-friendly, you've got to bake it into the data model. A good starting point is to us
by mumblemumble 7y ago
I think that this is one of those spots where, if you want things to be ORM-friendly, you've got to bake it into the data model.
A good starting point is to use CR instead of CRUD. Append-only tables with soft deletes aren't necessarily the most performant, but they're naturally less susceptible to race conditions. The lack of destructive modification (under normal operation) also makes it easier to diagnose problems and keep audit trails.
- slim 7y agoisn't soft delete an update?
- stevedewald 7y agoNot necessarily. You can insert a new row with a field named ‘deleted’ or similar set to ‘true’. This is how you would implement soft deletes in an append-only table.
- boublepop 7y agoIt doesn’t have to be. You Can write reads that don’t return entries if a separate deletion entry exists. Can’t say I’ve worked that way in sql, but I have seen that pattern in append only data structures. With for instance a “order fulfilled” entry essentially is a delete operation on an outstanding order entry.
- pocket_cheese 7y agoOne way I get around this is having an append only version of the main table, and then a "most current record" version of the table. My append only table will be a running record of all the data I've loaded unmodified. Then I run a create table as select statement against my append only table to generate my new version of the final table. So in essence, I'm "deleting" the old version of the record by omitting it when I create my new version of the final table.
- chrisjc 7y agoDefinitely an advantage on the other side of your traditional "CRUD" application... The data warehouse and BI stack.
- deleted 7y ago[deleted]