[FX.php List] PHP restriction on data transfer?
beverlyvoth at gmail.com
Sun Mar 22 18:50:26 MDT 2015
-- sent from myPhone --
> On Mar 22, 2015, at 8:10 PM, "Tim 'Webko' Booth" <tim.webko at gmail.com> wrote:
> However, I believe that I can control the number of records returned if I query the sub-table, which I can't do through the portal.
> And it also sidesteps the issues that have been noted with the portal code/XML at various stages...
>> On 23 March 2015 at 11:07, Malcolm Fitzgerald <malcolm at notyourhomework.net> wrote:
>>> On 23/03/2015 2:28 am, Bob Patin wrote:
>>> and that they should pull related records rather than pulling a portal? I don’t ever pull directly from portals, which may be why I’ve never seen this issue.
>> Portals are not the problem. They present the same issue that any table does - a portal represents a record set. The more important issue is that each record set also represents a query and possibly a sort. Data size on the network is less and less of a problem, so the extra number of records obtained by portals is not the problem. The processing of a separate query for each record in a found set is the real performance hit.
>> Call a portal P
>> Call the number of portals on a layout p.
>> Call the number of portals rows displayed by a portal x. If the scroll bar is displayed the number of portal rows is limited by memory, so x < ∞.
>> Call the number of records in the found set n.
>> When searching on any layout you will perform 1 + ( p * n ) queries and the found set will return n + ( n * (P1*x1 + P2*x2 ... Pp*xp) ) records
>> You can see, that the size of n is just as important in this equation as the size of p. For each record you will have to perform 1 + p queries. Which is exactly the same amount of queries that you would have to do to obtain the data set if you do not use portals.
>> What's more, in the real world, the number represented by n is more likely to be large than the number represented by p. (You are more likely to have more records in a table than portals on a layout). If n doesn't get larger than one (1) you won't see performance problems with portals. So, control the size of n and let p look after itself.
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FX.php_List