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

[Tim 'Webko' Booth]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20150323/efc56df0/attachment.html