INTRODUCTION
Earlier this month I was contacted by a DevCon presenter asking permission to include some slides from my eleven-year old anchor/buoy materials as part of his presentation. I said I’d be honored, but then added, “You might mention that I haven’t used A/B on a new project in about eight years.” He asked what system I was using instead, and a number of other colleagues have wondered as well, which brings us to the topic of today’s article.
Note: Anchor/Buoy has recently gained a new lease on life thanks to the selector-connector technique. In my opinion, A/B’s drawbacks outweigh its benefits, selector-connector notwithstanding.
Various developers have told me over the years that their main reason for adopting A/B was that it gave them a clearly-stated specific set of guidelines to follow with regards to graph management; with this in mind I have enumerated a set of post-A/B guidelines below, which I believe to be clear and specific.
To avoid any misunderstanding, I am in no way suggesting that the FM community should adopt my way of doing things — or that those who practice A/B are doing anything wrong. These are my thoughts on the subject, and as the saying goes, your mileage may vary.
THE BACKDROP
First I’d like to ask you to mentally rewind to March 2004, and recall the disruptive paradigm shift that occurred with the release of FileMaker 7. Suddenly developers were confronted with a myriad of contextual issues that had hitherto either a) not existed, or b) been handled implicitly by FileMaker behind the scenes. A common lament at that time was “We’re all newbies again” (another was “I’ll stop using 6 when they pry it from my cold dead fingers”).
Clearly the FM 7 relational model was significantly more powerful than its predecessors, but many experienced developers felt a sense of unease, bewilderment and/or deep philosophical and emotional angst when confronted with the Relationships Graph.
Below is an early incarnation of my first FM 7 graph. Like many, my inclination was to build something bearing a strong resemblance to an entity-relationship diagram (ERD), and I worked out some of the nuances of the data model directly on the graph.
However, as I noted at the time, while the Relationships Graph plays a vital role in all three “layers” of a database solution…
…an ERD only describes this layer:
A/B TO THE RESCUE
So, emulating an ERD on the graph appeared to be a dead end, and I disavowed it…
…and was quite happy to do so, having in the meantime discovered and embraced anchor/buoy. For the next few years I used A/B on all my projects, and evangelized it online, in print and in person.
But there was always a bit of cognitive dissonance. For one thing, at various times respected FileMaker luminaries such as Jimmy Jones, Ray Cologon, Ugo Di Luca, Mikhail Edoshin, and at least one FileMaker engineer, declared that A/B was a flawed methodology.
For another, it didn’t take a genius to see that this…
…was more intuitive and less convoluted than this:
(In fairness, I have never seen an A/B solution with a level of redundancy that was quite this extreme, but it does demonstrate what would be necessary to fully replicate the functionality of the non-A/B version.)
Also, as time passed the post-6 paradigm began to make more sense, and contorting FM7+ to emulate FM6 no longer felt as necessary as it previously had.
And, finally, evidence began to accumulate that additional TOs on the graph were not “free”, and that the profusion of joins could negatively impact solution performance.
To cut to the chase, while I continue to work on various teams where A/B is the in-house standard (and some where it is not), I made a decision in 2008 to stop using A/B on my own projects.
A POST-A/B EXPERIMENT
So, when one stops using A/B, what does one replace it with?
I have occasionally experimented with natural language TO naming… but only on small systems that are not expected to evolve into large systems. Shown here is an entire graph, not a subset of a larger one.
One thing I like about this approach is that the TO names help to document the solution… but this approach does not scale well, and I would not consider using it except on the simplest projects.
POST-A/B AIMS AND METHODOLOGY
Currently my aim is to strike a balance between having my graph resemble an ERD on the one hand, and retaining certain things I like about A/B on the other… e.g., a rock solid, easy-to-use naming convention. If I had to sum up my post-A/B methodology in a single sentence, it would be: “Connect everything, except when it makes more sense not to.”
Shown below is a portion of a graph from a complex project, and it represents approximately 25% of the total graph. Note that there is one large TOG (table occurrence group) followed by four smaller TOGs. Since this is a subset of the total graph, you will see a number of buoys without seeing their corresponding anchors — yes, I know, referring to TOs on a non-A/B graph as “anchors” and “buoys” may seem strange. For a while I tried to force myself to use other terms, but I still think of them as anchors and buoys, and it would be disingenuous to pretend otherwise.
GUIDELINES
These are general guidelines, as opposed to hard and fast rules, and one should feel free to make exceptions as necessary (e.g., see the note following #14 below).
- Each table has a single authoritative representation on the graph, i.e., an anchor
- Layouts are always attached to anchors
- Calculations, auto-enter calcs, etc. always “start” from anchors
- All other TOs are referred to as buoys
- Table names are always a single word and never contain underscores
- Anchor name = table name
- Buoy names reflect the path from the anchor (e.g., contact_scan_SCANMISC)
- Underlying table name in all UPPERCASE on both anchors and buoys
- Color coding reflects the underlying table
- Except grey is used for all minor tables
- On the graph, anchor TOs are expanded, buoys are not
- Underscore characters…
- Only appear in buoy names
- Are used as a table separator exclusively
- Multiple consecutive underscores are not used; they will only cause confusion, and #3 and #10 render them unnecessary
- Where desirable, a period can be used to append a descriptive label
- But only on buoys; never on an anchor
- Buoys can stretch leftward or rightward from anchors; direction doesn’t matter
- TO lists reflect the hierarchy of buoys below their parent anchor, e.g.,
- Anchors can be linked to other anchors via primary and foreign keys
- …in effect forming a pseudo-ERD
- However, if you don’t see an obvious spot for an anchor in one of your pseudo-ERDs, instead place it in a separate TOG
- For example, SCAN makes many appearances on the RG, but there isn’t one obvious place the anchor belongs, so it gets its own TOG
Note: if you take a close look at the graph example, you may wonder why SYSTEM is connected to ITINERARY since it appears to deserve its own TOG as per the preceding.
Explanation: the SYSTEM table provides the foundation for a dashboard used by administrators. The dashboard layout contains a number of portals, and originally SYSTEM was given its own TOG. However, after I had built a considerable amount of functionality into the dashboard interface, the client requested access to much of that same functionality from within a tab panel on an ITINERARY layout. Making an exception (to #14 above) and connecting SYSTEM directly to ITINERARY neatly solved the problem, saving considerable time, money, aggravation and graph bloat.
CLOSING THOUGHTS
Two of my favorite things about FileMaker are its depth and its flexibility. There is rarely a single best way to do things, and what works for me, of course, may not work for you. The above methodology provides a system that is as “automatic” as A/B, but that I find to be more cohesive, clear-cut and easier to work with. Bottom line: moving away from A/B has been like a breath of fresh air for me, and I don’t regret the decision at all.