1 Reply Latest reply on Dec 9, 2008 2:33 PM by TSGal

    slow relations



      slow relations


      Hello, I migrate from 5.5 to 9.

      I have a diary, with 1 relation for every half hour from 8:00 AM to 8:30 PM: 26 slots x day and format for "weekly" and "daily workgroup" visualization. Every slot is a relation: 26 [daily] + (26*7)[group 7 users, daily]. In 5.5, multifile solution, with older hardware, all was reasonable fast. The solution, automatically converted, is similar in speed. The solution, redrawn from skratch in 9 is painful slow. In the old version, the key is a calculated text field that combines the name of the user, the day, and the hour.

      In the new version, I have catch the ability to set relations with more than a key: 1 = user, 1 = date, 1 ≥ start hour, 1 < end hour, without calculated field. And all is in a monofile/multitable solution.

      I think the point is bidirectional relations: every single change in the the record (modify data, or user, or hour)  probably start a recalculation for all the relations... every when this is unnecessary; or may be that a multikey relation is so slower than a single key relation?

        • 1. Re: slow relations



          Thank you for your post.


          The more keys added to a relationship, the more evaluating it needs to do.  Previously, your calculated key makes one reference and is easy to look up.  Now, it looks up four different criteria.


          It shouldn't be that much slower.  I have one table with five keys, and the result is fast (< 1 second with 25000 records).  Then again, I don't change the keys, and I don't have a range for Start Hour and End Hour.  If you modify the key, then it has to calculate the relationship again and link to the appropriate records.  You may want to consider combining two of the equality fields (instead of the date fields that use "less than" and "greater than" operators).  This may help with the speed.



          FileMaker, Inc.