[FX.php List] PHP restriction on data transfer?

[Beverly]

:)
Yep!

-- sent from myPhone --
Beverly Voth
--

> 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...
> 
> Cheers
> 
> Webko
> 
>> 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.
>> 
>> Malcolm
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
> 
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20150322/abf66ee5/attachment.html