# How Do You Approach the Anchor-Buoy Principle? **URL:** \ **Category:** Floating Topics\ **Created:** [February 16, 2025, 10:54am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654 "2025-02-16T10:54:37Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![janhagemeister](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@janhagemeister](https://the.fmsoup.org/u/janhagemeister)\ **Post date:** [February 16, 2025, 10:54am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/1 "2025-02-16T10:54:37Z")
Dear FMSoup community, I am curious to know whether you: 1. Strictly follow the Anchor-Buoy principle, 2. Consciously choose to deviate from the Anchor-Buoy principle in certain cases, 3. 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. I would love to hear your thoughts on this! Thank you Jan ---
**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\ **Post date:** [February 16, 2025, 12:01pm UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/2 "2025-02-16T12:01:36Z")
For new projects, strictly anchor-buoy ---
**Author:** ![planteg](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/planteg/32/627_2.png) [@planteg](https://the.fmsoup.org/u/planteg)\ **Post date:** [February 16, 2025, 5:26pm UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/3 "2025-02-16T17:26:29Z")
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. ---
**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\ **Post date:** [February 17, 2025, 2:36am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/4 "2025-02-17T02:36:12Z")
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. ---
**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\ **Post date:** [February 17, 2025, 5:11am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/5 "2025-02-17T05:11:58Z")
There are some interesting thoughts about this in [Best Practices for Table/Relationship Conventions](https://the.fmsoup.org/t/best-practices-for-table-relationship-conventions/4585) ---
**Author:** ![harvest](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/harvest/32/231_2.png) [@harvest](https://the.fmsoup.org/u/harvest)\ **Post date:** [February 17, 2025, 9:23am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/6 "2025-02-17T09:23:56Z")
never ever something else than Anchor-Buoy ---
**Author:** ![LucThomaere](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/lucthomaere/32/3108_2.png) [@LucThomaere](https://the.fmsoup.org/u/LucThomaere)\ **Post date:** [February 17, 2025, 10:42am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/7 "2025-02-17T10:42:10Z")
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 ---
**Author:** ![bdbd](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bdbd/32/620_2.png) [@bdbd](https://the.fmsoup.org/u/bdbd)\ **Post date:** [February 17, 2025, 6:29pm UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/8 "2025-02-17T18:29:48Z")
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. ---
**Author:** ![weetbicks](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/weetbicks/32/206_2.png) [@weetbicks](https://the.fmsoup.org/u/weetbicks)\ **Post date:** [February 18, 2025, 1:57am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/9 "2025-02-18T01:57:10Z")
Anchor Booee for sure. ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [February 18, 2025, 2:07am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/10 "2025-02-18T02:07:59Z")
> [@Kirk](#): > > 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. - do you have a link for this? - 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!) ---
**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\ **Post date:** [February 18, 2025, 3:20am UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/11 "2025-02-18T03:20:25Z")
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 analysis is on the 24u site. Anchor-buoy mitigates this issue. ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [February 18, 2025, 3:21pm UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/12 "2025-02-18T15:21:59Z")
Here's what I found over on [24usoftware.com](http://24usoftware.com) regarding FMS 2024: [Link](https://24usoftware.com/news/filemaker-performance-update-2024) > The next test we focused on was the impact of specific improvements reportedly brought in the new version. [Release notes for FileMaker Server 21](https://24usw.com/4joonln9d) 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](https://24usoftware.com/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... ---
**Author:** ![Dutchman](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/dutchman/32/491_2.png) [@Dutchman](https://the.fmsoup.org/u/Dutchman)\ **Post date:** [February 18, 2025, 6:07pm UTC](https://the.fmsoup.org/t/how-do-you-approach-the-anchor-buoy-principle/4654/13 "2025-02-18T18:07:11Z")
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.