7 Replies Latest reply on Mar 20, 2013 1:05 PM by steve_ssh

    Filtered portals vs portals based on globals

    PeterWindle

      Hello everyone!

       

      I have a solution that uses many portals (and therefore many realtionships) showing related data from another single related table.

      All the portals are displayed on the one layout.

       

      At the moment, I am using multiple relationships, each portal displays values from the one related table using globals. The globals change on a fairly regular basis. (it's a little bit like a 'console' application). Changing one global usually changes all the other globals, therefore, everything else from the related table changes, giving a summary of all sorts of info.

       

      I was thinking that it might prove to be better performance if I change the many relationships to a single relationship and simply use 'filters' on the portal (using the same globals) to show the related info I need.

       

      But, before I make the change, I wanted to know if there would be any performance benefit? The solution is on a WAN and it can be slow displaying multiple portals to the one table on the one layout.

       

      Anyone have any ideas about this?

        • 1. Re: Filtered portals vs portals based on globals
          gdurniak

          Filters are never faster.  They do a "table scan",  looking at each record,  rather than an index as a relation does

           

          but if the total found set is small,  it may not matter

           

          greg

           

          > I was thinking that it might prove to be better performance if I change the many relationships to a single relationship and simply use 'filters' on the portal (using the same globals) to show the related info I need.

           

          But, before I make the change, I wanted to know if there would be any performance benefit?

          • 2. Re: Filtered portals vs portals based on globals
            debi

            PeterWindle,

             

            Just a couple of additional caveats about filtered portals: if you sum them, or use a GTRR on the group, FileMaker does not consider the filtering and uses the full set of related records.

             

            Debi Rubel

            FullCity Consulting

            • 3. Re: Filtered portals vs portals based on globals

              Hi Debi,

               

              Actually i believe that  you can GTRR to filter portal set but you must be in the portal for it to work.  Child summary fields ( placed within same filter ) also works.  But I agree that relational filters are FAR better because as Greg says portal filter must walk all 'relationally-related records. 

               

              Peter, best to use relational filter ALWAYS and then you can filter THAT relationship down further using portal filter if desired.

              • 4. Re: Filtered portals vs portals based on globals
                Mike_Mitchell

                Peter -

                 

                The above advice is sound. I am curious, though, when you say, "everything else from the related table changes, giving a summary of all sorts of info". Can you elaborate just a bit? This might be where your performance issue is coming from, rather than from the use of relational joins.

                 

                Mike

                • 5. Re: Filtered portals vs portals based on globals
                  Oliver_Reid

                  I have done this with no apparent speed loss, and a much simpler TOG. 


                  I have each portal in separate tab for each diffrent filder, so they don't all redraw at once afaict. Becauee thaye are based on teh same to, I beliver Fm does not have to repeatedly load the portal - just load once and filter diffrently view each view (case anoyme confirm this assumption?) . This scheme enables a user to drill down to specifc related record very quickly.


                  I would suggest making 2seperate copies of the layout with a few portals on each done each way and comparing rendering speed.

                  • 6. Re: Filtered portals vs portals based on globals

                    Debi, I stand corrected ... I see you said GTRR to GROUP does not work and you are correct since one can't drop into a portal on an entire record set.  And Sum() would not work since it looks at relationship only. :)

                    • 7. Re: Filtered portals vs portals based on globals
                      steve_ssh

                      While the portal filter performs its work no faster than a relationship, I have encountered a scenario in which the overall performance of a portal was improved by removing some of the predicates from a relationship, and moving them into the portal filter.

                       

                      The scenario in question was where the child table had a large number of records, and the original relationship included  > and  < comparisons.  (These comparisons were being applied to a date field, the idea being to match child records linked to a particular user, and then further "filter" to a date range.)

                       

                      The inequality comparisons really slowed down what would otherwise be a very speedy relationship.  My hunch was that the inequality comparisons were being evaluated in a "table-scan" type fashion, so I removed the inequality comparisons out of the relationship, and applied them at the portal-filter level.  Because the portal filter was performing its task against a greatly reduced set of records, the overall performanceof the portal went from ununsably slow to perfectly speedy.  This was in FM 11.

                       

                      In the past I've read through various posts on the topic of whether or not it is possible to determine the order of predicate comparisons in a FileMaker relationship, and felt that there didn't seem to be a consensus on this topic.  While this thread is probably not the best place to pursue that particular topic, I mention this in case there is a way to enforce the order of predicate comparisons, then my above observation is much less noteworthy.

                       

                      Best,

                       

                      -steve