The REPL: Issue 95 - July 2022

1 year ago

source link: https://ylan.segal-family.com/blog/2022/08/08/the-repl-issue-95-july-2022/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

The REPL: Issue 95 - July 2022

Aug 8, 2022 • Ylan Segal • the repl

The Bullshit Web

Nick Heer laments the state of the current web. Modem speed in the 1990s were 56K modem (I started connecting with the internet on a 14.4K connection). Connection speeds are orders of magnitude faster, and yet web pages still feel slow. It’s the bloat. The embedded videos you don’t watch, the trackers, the ads. It’s all bullshit.

Failed #SquadGoals

Jeremiah Lee writes about the famed Spotify model. It was copied and talked about widely. It turns out, not even Spotify used that model. At least not to the extent that was implied in the original whitepaper. Remember that what you read companies are doing in their blog posts and whitepapers might not be exactly what they are doing, and when they move on to something else, they rarely go back to talk about the mistakes that they made in the first place.

Soft Deletion Probably Isn’t Worth It

Brandur contends that soft-deletion is usually not worth it. It’s rarely used, complicates the model, and on top of that breaks foreign keys. I agree with all that. Especially loosing foreign keys. As an alternative, he proposes using a generic deleted_records table, storing most of the columns in JSON, and populating on deletion. It preserves foreign keys, and preserves the audit ability for customer support. He doesn’t mention it, but it strikes me that it can easily be partitioned for scalability.

There is another alternative I’ve written about: Temporal Modeling. The issue with temporal modeling, is that it also looses foreign key constraints as they are implemented in typical relational databases. The database can still enforce via constraints on date ranges, but it requires a lot more work. I wish there was a Postgres extension that was temporal modeling aware and simplified constraint generation.

Find me on Twitter at @ylansegal

Recommend