4 ms·
I don't get why it is a paper? Just make multiple requests SELECT ... FROM TABLE. You can batch them if you like, or just send out multiple requests in parallel
by quickthrower2 3y ago
I don't get why it is a paper? Just make multiple requests SELECT ... FROM TABLE. You can batch them if you like, or just send out multiple requests in parallel.
Infact this is what some shitty ORMs do when you don't want them to do this and you actually wanted a join. (Grrrr!). Sometimes you want the opposite. The complaint is more that ORMs do silly things and there is less control.
I am guessing the paper is really about some nice sugar for doing this?
- sargstuff 3y agoit's either 'select groups of tables in database and make a new database' or api for behind the scenes 'duplicate the database and remove data not interested in'
- da_chicken 3y agoMultiple selections have to transfer possibly redundant data. By returning the data once and querying it clientside, you avoid having to do that.
- butlerm 3y agoThe main application for this is where you have detail data for parent records in a snowflake pattern. In that case SQL tends to require a ridiculous number of queries, where common formats like JSON and XML are capable of transferring hierarchical data like that in a single response. That is a major weakness of SQL and the common inability to return a hierarchical set of relations in one response in particular. Also, running a ridiculous number of queries in parallel is not practical on many databases due to per connection overhead, a problem that is so severe that many databases have internal many-to-one connection demultiplexers already, i.e. they have N execution engines for M connections. That should sound familiar to those who are familiar with threading models.