5 ms·
If this isn't a business application, ignore this entire comment. If it is a business application, you probably shouldn't build a CRUD app, at least not the wa
by slotrans 5y ago
If this isn't a business application, ignore this entire comment.
If it is a business application, you probably shouldn't build a CRUD app, at least not the way that's commonly understood. Stick with me for a minute.
First off, you must never delete business data (except per GDPR, retention policies, or other legal requirements). I'm sure someone will pipe in with a contrived use case where you would want to, but in general you must not. Soft-deletes, sure. Hard deletes with immutable history, also ok. Generally the popular frameworks will not help you here.
Second, realize that an update is logically equivalent to a delete followed by an insert (under the hood, Postgres implements `update` precisely thus). So per the above, you should think twice about updates. As with deletes, an immutable history can make updates safe. Alternatively, you can use append-only versioning with a current version pointer. Again, the frameworks are just not going to help you here.
So out of CRUD that leaves just CR that are fully safe, and those are the easiest parts.
I'm sure most folks will think this is ridiculous but that's because "building business software" is 1) not taught in school, 2) considered hopelessly boring, and therefore 3) not valued by developers. Nevertheless, it's generally, y'know, our job. Good business software must keep records. It must track when things happened, who did them, and so on. The typical approach to CRUD, as exemplified by all the frameworks suggested in other comments, does not keep such records, and therefore produces software that is unfit for its purpose.
One common objection will be that you don't need these things, or don't know that you need these things, at the beginning of a project. Yes you do! Imagine telling the IRS "oh I didn't keep very good records this year, after all my business is just getting started". Record-keeping needs to be treated as a hard, non-negotiable requirement for all business software.
- cookiengineer 5y agotips hat in a grumpy voice Damn, take my upvote. You're right and you won.
- pooya72 5y agoYes. Anyone that's worked with accounting software knows this. There is no delete or update. It would insane to update a transaction that happened three months ago. You have to do a reverse transaction. Actually, MediaWiki works the same way. You can see the history.
- pjc50 5y agoDurable records are actually legally mandated in France under "NF525": https://www.ikosoft.com/en-gb/all-knowledge-about-the-nf525-standard-for-cash-register-software/ https://www.ikosoft.com/en-gb/all-knowledge-about-the-nf525-...
- jamil7 5y agoWe ended up with a system like this too but came at it from another angle - building offline sync. After reading your comment though I realise it can be more widely applied.
- macintux 5y agoExcellent comment. I will say this: as someone who has to interact with a system where nullifying and deleting data is a legal requirement for privacy reasons, I desperately wish that weren’t true. Auditing, tracing, even basic production robustness…everything just seems to fall apart when one can’t follow your model.
- deleted 5y ago[deleted]
- bcrosby95 5y agoWe just use our log as a history if we need it. We very rarely need it. Obviously it depends upon your exact domain. But overbuilding history can be a mistake too.
- _448 5y agoWhat stack would you suggest for this? Or what are the recommended approaches to achieve history/versioning of the data? EventSourcing/CQRS is one that I know, but are there other ways to achieve that by using Postgres?