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
> 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?
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.
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.
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.
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.
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. :)
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.