[HN Gopher] Yagri: You are gonna read it
___________________________________________________________________
Yagri: You are gonna read it
Author : escot
Score : 36 points
Date : 2025-04-23 21:47 UTC (1 hours ago)
(HTM) web link (www.scottantipa.com)
(TXT) w3m dump (www.scottantipa.com)
| al_borland wrote:
| I agree with this as written, as think it's important to have
| some degree of forethought when building out the DB to plan for
| future growth and needs.
|
| That said, the monkey paw of this would be someone reading it and
| deciding they should capture and save all possible user data,
| "just in case", which becomes a liability.
| arjonagelhout wrote:
| A little while back, I had a conversation with a colleague about
| sorting entries by "updated at" in the user interface, and to my
| surprise this was not added by the backend team.
|
| Many of these "we are going to need it"s come from experience.
| For example in the context of data structures (DS), I have made
| many "mistakes" that I do correctly a second time. These mistakes
| made writing algorithms for the DS harder, or made the DS have
| bad performance.
|
| Sadly, it's hard to transfer this underlying breadth of knowledge
| and intuition for making good tradeoffs. As such, a one-off tip
| like this is limited in its usefulness.
| SchemaLoad wrote:
| Somewhat related, but I suggest having both the record updated
| at, and some kind of "user editing updated at". As I've
| encountered issues where some data migration ends up touching
| records and bumping the updated at, which shocks users since
| they see the UI reshuffle and think they have been hacked when
| they see the records updated at a time they didn't update them.
| XorNot wrote:
| I mean this is what audit logs are for I'd say: generally
| speaking you want to know what was changed, by who and why.
|
| So really you probably just want a reference to the tip of
| the audit log chain.
| reillyse wrote:
| One thing I do quite frequently which is related to this (and
| possibly is a pattern in rails) is to use times in place of
| Booleans.
|
| So is_deleted would contain a timestamp to represent the
| deleted_at time for example. This means you can store more
| information for a small marginal cost. It helps that rails will
| automatically let you use it as a Boolean and will interpret a
| timestamp as true.
| seveibar wrote:
| Agree, although the acronym in the article could be interpreted
| to mean "you are going to read it, so index it appropriately",
| which is sort of bad advice and can lead to overindexing. There
| is probably something better for "add appropriate and
| conventional metadata" (the author suggests updated_at,
| created_at etc)
|
| Not a huge fan of the example of soft delete, i think hard
| deletes with archive tables (no foreign key enforcement) is a
| much much better pattern. Takes away from the main point of the
| article a bit, but glad the author hinted at deleted_at only
| being used for soft deletes.
| mkhalil wrote:
| Event-sourcing solves this. And with how cheap storage is, it
| should be more prevalent in the industry. IMO the biggest thing
| holding it back is that there isn't a framework that's plug-and-
| play (say like Next.js is to React) that provides people with
| that ability.
|
| I've been working on one in Typescript (with eventual re-writes
| in other langs. like Rust and Go), but it's difficult even coming
| up with conventions.
| rising-sky wrote:
| Care to share what you've been working on?
| evanmoran wrote:
| Just curious, how do people feel about this general style of soft
| deletes currently? Do people still use these in production or
| prefer to just delete fully or alternatively move deleted rows to
| a separate tables / schema?
|
| I find the complexity to still feel awkward enough that makes me
| wonder if deleted_at is worth it. Maybe there are better patterns
| out there to make this cleaner like triggers to prevent deletion,
| something else?
|
| As for the article, I couldn't agree more on having timestamps /
| user ids on all actions. I'd even suggest updated_by to add to
| the list.
| swagasaurus-rex wrote:
| I think soft deletes using timestamptz are a good thing.
|
| Deleting rows directly could mean you're breaking references.
| For example, say you have a product that the seller wants to
| delete. Well, what happens if customers have purchased that
| product? You still want it in the database, and you still want
| to fulfill the orders placed.
|
| Your backend can selectively query for products, filter out
| deleted_at for any customer facing queries, but show all
| products when looking at purchase history.
|
| There are times when deleting rows makes sense, but that's
| usually because you have a write-heavy table that needs
| clearing. Yes, soft-deletes requires being careful with WHERE
| statements filtering out deleted rows, but that's a feature not
| a bug.
___________________________________________________________________
(page generated 2025-04-23 23:00 UTC)