the Client somehow got to itself lists of keys, surrenders to me that it subtracted these from the server, instead of invented.
Whence these lists undertake?
Most simple - loading (or any other operation) with the big list of entities on which the user wants to see progress.
Then the first Select query Id from... join....
We learn, how many all will be lines as a result, and then we fulfill operation (we load on the client) packs on 100-1000.
Especially actually, if the client is connected not a DB, and to an application server on HTTP and on each request at the client a limit on time and the size of a packet.
There was still a variant of usage FB as stupid key-value storage.
The hand control in an application server was applied.
All join become in storage, and lines are loaded under list Id, only what else are not present in storage . Strongly saves kol-in readings from a DB.
And at last. Relations many-to-much.
Master essence in the table from 30 million records, Detail - 3 million records and links in between - more than 300 million (the separate table with links on master and detail for each communication, all on the best experts).
And here is how time join to the table links began to choke (because not on unique index?).
Followers of the pure relational theory can be spat, but the fact is the fact.
After transfer links in the table master it is stupid in a string field varchar (3000) id-shniki through a comma, and reading details under list Id (where DetailId in (121,122,123...)) loading so decreased that the system has been rescued.
a teddy bear wrote:
I to you one clever a thing will tell, only you do not take offense please ()
At you experience is too restricted, and to me to take offense?