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

[Bob Patin]

I agree with Tim; what I do is to do 2 queries: query the parent record, then pull the related records in a 2nd query.

I certainly wouldn't be doing a query for each related record though...

Bob Patin
Longterm Solutions
bob at longtermsolutions.com
615-333-6858
FileMaker 9, 10, 11, 12 & 13 Certified Developer
http://www.longtermsolutions.com
-
iChat: bobpatin at me.com
Twitter: bobpatin
—
FileMaker Consulting 
FileMaker Hosting for all versions of FileMaker
PHP • Full email services • Free DNS hosting • Colocation • Consulting

> On Mar 22, 2015, at 7:07 PM, 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