4 ms·
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.
by ebiester 8y ago
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.
- eweise 8y agoI 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.
- badestrand 8y ago> 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.
- scarejunba 8y agoMost stores of large scale do not run online calculation or modeling for “others also bought”. It’s usually offline.
- zaarn 8y ago"Show content your friends liked" is an easy example where you want an in database join, in userspace this operation would be incredibly slow.
- ddebernardy 8y agoIn 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 https://wiki.postgresql.org/wiki/Foreign_data_wrappers