3 Replies Latest reply on Feb 6, 2017 11:43 PM by Benjamin Fehr

    How do links affect performance?


      Let's accept that calcualtion fields can drastically affect performance.


      So, let's pretend that in a file there are no caclulated fields or extremely complex and trying relationsships. And let's limit the number of fields to a minimum.


      I ran into an unexpected problem with 4D using version 2 or so that was not documented in the manual. My first job for a client took forever to load on his new network (which wasn't very fast at all).. I was told later that the problem was the 4D wanted to load every record and relationship of the first table created. Naturally that was the main table... 


      I have developed the habit of making small nests of links rather than long winding chains that need a road map, usually less than four or five tables.


      Now, I am wondering seeing how much easier it is to just linik 50 tables together and avoid having 300TOS, if that is a viable idea.


      As further history I created a link of tables on a MacPlus that was probably 20 tables long with subtables of various depths. After finishing the design and with very little data, I opened the file to the first layout. It took 45 minutes to load. Today that would be seconds on my laptop with the same file.


      So, the question is whether it is OK to create a nest of octopi or preferable to create many nests of only a few tables linked together for a specific purpose.

        • 1. Re: How do links affect performance?
          Jason Wood

          I believe FileMaker only looks at the graph when it needs related data, and then it only goes along the path to where it needs to go. I don't think it makes any difference how many extra table occurrences might be connected to the same TOG if they aren't being used at that moment.


          On the other hand, I've heard that each TO contributes to load time (when you open the file), so perhaps larger TOGs will help your load time if it means less TOs overall.


          There are many different opinions about what is the best way to organize a relationship graph. I would say that the best way is probably the one that's easiest for you to understand and maintain. Personally, I use a slightly relaxed version of "anchor-buoy"–somewhere between strict anchor-buoy and the relaxed adaptation described here:


          • 2. Re: How do links affect performance?
            Markus Schneider

            technically, it might be fine - but You'll lose overview...


            If You got somewhere in Your chain a condition depending on a field that has to be set _before_, it's possible that You pick that TO later under circumstances where that field is not set correctly - boom


            It's also possible to pick the 'wrong' TO, resulting in deleting wrong items




            Therefore, we prefer the anchor buoy method and recommend strongly to go that way


            We've found solutions with huge nested/chained relationship graphs - performance in a LAN for users wasn't a problem - but maintaining those solutions was a nightmare

            • 3. Re: How do links affect performance?
              Benjamin Fehr

              also my recommendation:

              search some articles about "Anchor-Buoy".

              If your solution doesn't meet your expectations, 'specially when a bottleneck like WLAN-Clients are involved, you might go a step further with the "Selector - Connector" method.