Consciously choose to deviate from the Anchor-Buoy principle in certain cases,
Or do not use it at all.
I see the FileMaker Anchor-Buoy principle as a design pattern. And as with all design patterns, it serves well as a template for specific use cases. After all, in other programming languages, I also don’t apply the Factory pattern or Dependency Injection for everything.
IMHO Anchor-Buoy is the way to go, right from the start. A Spider Relationship Diagram is sure to get you in troubles one day or another. And converting a Spider to Anchor-Buoy is a big chore.
As Honza @ 24u benchmarked - noting that every relationship in FM is in effect, a query - the more relationships that exist in a table occurrence group (TOG), the lower the performance ……. and not by a little bit.
His benchmark test signaled the end of the highly functional selector-connector model, exposing a key performance pitfall of NOT adopting anchor buoy TOGs.
Very right!
The only problems I've ever had with relationships was when I did NOT use the anchor-bouy structure.
Use it even for the smallest projects because small projects can grow and then your troubles will start
Anchor buoy for structure for several years. I deviate a lot in the naming convention. I am now thinking of deviating some more for it seems to me that basing a layout on a buoy can be beneficial from time to time.
have the benchmarks been done with FMS19, 20, 21? I ask because a few of the improvements recently have mentioned improving the caching behavior of relationships. (personally, I've only seen relationship slowdowns, but I'm open to the idea that there could be speedups!)
The rationale is that every relationship, as a query, needs to be evaluated to see if impacts to data exist. The more relationships, the greater the execution time.
The next test we focused on was the impact of specific improvements reportedly brought in the new version. Release notes for FileMaker Server 21 mentioned caching of field definitions. The new version was also supposed to have the caching of relashionship graph improved, so we were interested whether and how much it improves the known issues. Since we already have a related focused test part of BenchTest (the Slow Graph test contributed by Vincent Lugnier some years ago when he reported a huge slow-down caused by a relationship graph with many broken relationships) we ran this test 100 times in each version. Sadly, this particular test got even slightly slower in FileMaker 2024...
I feel like there's no bright line separating my approach from A-B as it's generally defined. I absolutely go for small TOGs and avoid Spider Graphs at all costs. In the end I don't need to link everything on the relationship graph. Using scripts to manage access to different layouts with different contexts (made so much better with card windows) means I can keep my TOGs tightly focused by function. eSQL helps reduce the need for connected TOs that much more.
Where I differ from it the most is in the naming convention. My solutions are relatively small (usually less than 30 tables or 100 TOs). If the solutions were much bigger than this, I suppose I could see where "true" AB is a better default. But as others have said, too much dogma can be a bad thing, so I use it more as a design pattern, as you describe it.