Jump to content
Salesforce and other SMB Solutions are coming soon. ×

No Anchor-Buoy!


Feirefiz
 Share

Recommended Posts

Is anyone familiar with FileMaker how-to books, resources, sample files that do not use the anchor-buoy model?

 

Question 2: Anchor-Buoy also seems to be known as the "squid" model. What are the names of the other approaches? Practically everything I find under "spider" tends to be negative, and I've also found the negative "spaghetti" approach.

Edited by Feirefiz
added a 2nd question
Link to comment
Share on other sites

“Spaghetti” is the “no-approach approach“, aka “organic growth”, aka entropy …

 

See here

 

https://www.dropbox.com/s/hmp3v80z31g7zlu/approaches_to_graph_modeling.pdf?dl=0

 

for a White Paper from the mothership, penned by the master himself – which btw. I translated for FM Germany … holler if you'd like the German version.

Edited by eos
Link to comment
Share on other sites

It says it's got 0 bytes. Anxious to see who the master is!

 

About spaghetti, yeah, but what are the names for the good (alternative) versions? Maybe it's in the white paper.

Link to comment
Share on other sites

Ah ja, thanks. eos, now that I know who the master is: is there more about these other relationship models in the FileMaker Bible? That is, if you have & have read that book.

Link to comment
Share on other sites

There are a lot. Some have names. Some don't. Ray hit a bunch of them in that white paper eos linked.

 

Anchor-Buoy

Selector-Connector

Party Model

Mafia Model ( a reference by John Renfrew LOL )

Spaghetti

 

I've found which approach I use depends on the project. I don't remember the FM Bibles going into great detail about them. You'd be better off searching each one and trying to find blogs or videos about them.

Link to comment
Share on other sites

I've read the last FM Bible written by RC, which was for v10, but I don't remember the relationship section – in brief: dunno. Isn't that White Paper extensive enough …?

Link to comment
Share on other sites

This was his tweet about it on Aug 3, 2015. It makes me laugh every time I run into it.

 

new #filemaker relationship type, the mafia model - it's all about who thinks they are in control, and who really is

CLgPU7SWIAIUIOc.png:large

 

Link to comment
Share on other sites

The useful and logical way to set up relationships is "modular".

 

Here is how modular differs from the formal official anchor-buoy method:

 

 

ANCHOR-BUOY

 

• Anchor-buoy would have you create a new table occurrence for each table for which a layout exists (and, reciprocally, have each layout use that table occurrence), and place that table occurrence on the far left with a simple name such as Jobs or Clients or Assigned Personnel.

 

• Anchor-buoy would then have you string table occurrence of related tables off to the right of these "anchors" and name them according to the relationship path: Clients via Jobs perhaps, or Jobs to Clients, for a Clients table occurrence one step to the right of the Clients "anchor". For the next level in the hierarchy, i.e., table occurrences related to the first tier of relationships, you'd see names like Contacts via Clients via Jobs, or maybe Jobs to Clients to Contacts.

 

• All relationships, therefore, have a directionality; there is always a "more primary" side (the more leftward of the table occurrences is primary to the one to its right).

 

•*You end up with a lot of redundancy: the same set of fields that links Jobs to Clients via Jobs will probably show up a second time as the relationship beteween Clients and Jobs via Clients.

 

 

MODULAR

 

•*Modular design has you make use of the fact that there is no innate directionality in relationships. You design relationships in the order that you have need for them as you design; if you already devised a relationship between Clients and Jobs based on Client ID = Client ID, you don't need to designate one as primary, don't need to care which one is on the left or above or otherwise spatially related to the other; they're reciprocal.

 

• Modular design, although it does not inherenlty have its own naming convention (as far as I know), readily allows you to name table occurences in simpler, more straightforward fashion: Clients, Jobs, Contacts, Assigned Personnel, Invoices, etc. When you have need of a second relationship to a table that is already related (directly or indirectly), you can choose to give it a descriptive name (Primary Contact Person, PriorJobsSameJobType, etc); but there is no directionality or primacy reflected in naming conventions per se. Developers using modular deisgn tend to make sure the most basic connection between Clients and Jobs allows them to relate table occurrences called "Clients" and "Jobs" to each other, and to deploy more complex names for less commmonly encountered relational paths.

 

* You avoid redundancy. If Jobs is related to Clients and you're on a Clients layout and wish to reference fields in Jobs, you reference them as Jobs::FieldName. The fact that you created the relationship first while on a Jobs layout is irrelevant.

Link to comment
Share on other sites

AHunter3, thanks you for the clear description! And the name!

 

Josh, yeah, that's why my second question was about the names: so I could try to look up more. The tip about FM Bible is helpful.

 

eos, the white paper is a start… but you know how every FM tutorial & book gives lots of examples, walk-throughs, files so lovingly demonstrating anchor-buoy? Well, I was hoping to find something just as in-depth using the modular approach. Everytime I say to myself, hm, I want to take a look at how someone else links these relationships, I'm dismayed to discover it's anchor-buoy. My approach is (pretends / aspires to be) modular because it makes most sense to me without having to twist my brain in ways that don't seem natural (anchor-buoy). What I want to do is acquire a nice big fat book using the modular approach, but I'm not sure there is one.

Link to comment
Share on other sites

I've never seen one either. And in the books that tout anchor-buoy as the best practice, the examples given of what non-anchor-buoy relationships look like are all these hideous tangles with the relationship-lines overlapping: chaos!

 

But a modular relationship diagram need not be chaotic. Mine aren't. (This is from a 500+ table-occurrence solution I was responsible for 2006-2008). A good database environment is going to end up having some table occurrences that are primary, with zillions of relationships going from them to others, and other table occurrences that are obviously auxiliary, connecting mostly to one of the primary TOs, occasionally to one or two other TOs, but mostly arraying like satellites around the main TOs.

 

Use horizontal alignment to keep edges squared off, always sort your fields by creation order before working on the relationship diagram, always move your TOs as need be to keep the relationship "wires" from crossing, make use of labels to mark off table occurrrence groups (TOGs) if you end up using them, and keep your naming conventions straightforward, self-explanatory, and easy to type when you're freehand-typing in calculation formulas. Don't start off lots of TOs with the same 3-4 initial characters (it defeats type-ahead if you do) and avoid characters that require shift or other modifier keys to type in the first handful of chars of your TO names (also defeats type-ahead unless you've got spectacular typing skillz).

 

If you do use Table Occurrence Groups (I do once the solution reaches a certain threshold of complexity), consider using different colored labels as backgrounds for each TOG, then tinting all TOs wherever they occur to match the label color of the TOG that that table's primary occurrence is located in. Thus on my graph (linked above) any TO of Crew or any of the minor tables whose primary occurrence is also in the Crew TOG will appear tinted orange. Any TO of Store or of the minor tables whose primary occurrence is in the Store TOG will be tinted red; and so forth.

Edited by AHunter3
Link to comment
Share on other sites

Thanks a lot AHunter for these posts - I use the modular approach just the way you do, but now, without the subconcious feeling of being unprofessional!

Link to comment
Share on other sites

  • 1 month later...

I wonder if it's related to the left-to-right, top-to-bottom approach of anchor-buoy that you can extend the relationship graph to the right or down, but not to the left or top. Maybe this is improved in versions of FM later than 12? Or in the Hebrew or Arabic version?? Workaround: select all, move down to the right, then re-expand to the left or top.

Link to comment
Share on other sites

AHunter3, a question to your color-coding scheme: Do you also distinguish colors (or shades of colors) between TOs that have a different underlying table? So from your example above: "Any TO of Store or of the minor tables whose primary occurrence is in the Store TOG will be tinted red", if you have multiple underlying tables, would you choose different shades of red to differentiate them? I'm asking because I had been doing this, as well as for the primary TOG. Or I have one case of this, at any rate.

Link to comment
Share on other sites

AHunter3, a question to your color-coding scheme: Do you also distinguish colors (or shades of colors) between TOs that have a different underlying table? So from your example above: "Any TO of Store or of the minor tables whose primary occurrence is in the Store TOG will be tinted red", if you have multiple underlying tables, would you choose different shades of red to differentiate them? I'm asking because I had been doing this, as well as for the primary TOG. Or I have one case of this, at any rate.

 

Yes, I try to. For example, the main table "Crew" in the TOG also titled "Crew" has a prominent orange color. Various minor tables that have their "home occurrence" also in the Crew TOG will also have a shade of orange, but ideally each would have its own slightly different shade of orange.

 

All within the limitations of color diffs discernable on the graph, of course.

Link to comment
Share on other sites

 Share



×
×
  • Create New...

Important Information

Terms of Use