Hacker News Reader

For Insert/update/delete, that makes sense.

However, many times it makes sense to just do the join in the database rather than make an n^2 join in user space. This becomes problematic in collection cases - 100 cases belonging to 70 users. It's a quick left hand join but a slowdown in application space.

View on HN

I don't disagree but I think in practice you're probably dealing with a single user at a time when working with orders. A query that referenced n users plus their orders is probably a reporting type query that could be supported in a data warehouse where all the tables could be joined together.

> query that referenced n users plus their orders is probably a reporting type query

No, there are enough other valid cases, e.g. display last customers and their orders or some simple "others have also bought". In practice you will need to join a lot spontaniously and can not just defer that to a data warehouse.

Most stores of large scale do not run online calculation or modeling for “others also bought”. It’s usually offline.

"Show content your friends liked" is an easy example where you want an in database join, in userspace this operation would be incredibly slow.

In Postgres you can use a foreign data wrapper to do such a join with a wide number of 3rd party data sources.

https://wiki.postgresql.org/wiki/Foreign_data_wrappers

Reply on news.ycombinator.com