> Another classic is the “joins are slow” argument
The only person I knew who died on that hill would insist on doing two queries to the database, and then would insist on doing a client side cartesian join.
The only person I knew who died on that hill would insist on doing two queries to the database, and then would insist on doing a client side cartesian join.
I think many were burned by mysql back in the day - trying to use sql as a document database - or using php frameworks that happily did a hundred queries pr page view.
As a general rule of thumb, for a REST app - I'd say the db should be normalized, and the cache layer(s) can handle the denormalization.
Ie when you get /page=1 varnish can spit out a response from ram (which if you squint, is a denormalized projection of your data), or it can go talk to your app, that talks to the db. And the latter is most likely fast enough (tm).
While when using denormalized database, your read will have to go to the disk.
But each query will use a different copy of the same data instead of joining with the same copy.
Storing both copy in memory take more space so you can’t cache as much in memory.
I’m not talking redis or memcached but the page cache inside the sql engine.
Unlikely in practice, though.