Does Right to Left vs Left to Right Matter in Parent -< Join >- Parent Relationship?

[Guy_Smith]

Is there a difference in how Filemaker reads/acts on the two following Relationships:

1.  Parent Table A --< Join Table AB >-- Parent Table B  and

2.  Parent Table B --< Join Table BA >-- Parent Table A  ?

After my last disastrous foray into designing a Relationship Graph, I went back to the Filemaker Training Series to re-re-re-read about building correct ERDs and Relationship Graphs, but only managed to confuse myself even more.  The FTS examples all use the Anchor and Buoy concept, but seem to have a huge amount of unnecessary repetition, unless I'm completely off base.  Using their "04_Bonsai" Relationship Graph as an example, they have one Anchor-Buoy set of

ORDER --< order_LINEITEM >-- order_lineitem_PRODUCT        and another Anchor-Buoy set of

PRODUCT --< product_LINEITEM >-- product_lineitem_ORDER.  

These seem functionally IDENTICAL to me - you can even swap the icons around so the ORDER TO is on the left, the LINEITEM TO is in the middle, and the PRODUCT TO is on the right for both sets without changing the Relationships between them  (and yet a third set with LINEITEM on the left and both lineitem_ORDER and lineitem_PRODUCT to it's right, which can be manipulated to match the above two sets as well).

If i'm sitting on a record in the ORDER TO, looking through the LINEITEM TO into the PRODUCT TO, does it matter if I have to look left or have to look right?  Or are they just adding a bunch of Anchor-Buoy sets on the Graph to, ummmm, "clarify" process flows?  Are there any performance issues in eliminating the redundant TOs? Is it considered a Best Practice to place a TO on the left of the Graph for every Table and delineate Relationships to the right of each beginning TO?04_Bonsai Relationship Graph.pdf

 I have included a screenshot of the Relationship Graph (squished to fit) to illustrate my problem and, as always, your insights are greatly appreciated.

Sincerely,

Guy

[Wim Decorte]

Yes, the direction matters because context matters.  As you know layouts in FM are always based on a TO so you could be on a layout on either the left or the right hand side of that relationship.

[comment]

The placement of TOs on the relationships graph - whether absolute or relative to each other -  has no effect whatsoever on functionality.

There is a convention to place the parent on the left and child on the right.

If you're using the Anchor/Buoy method, then there's a whole set of additional conventions that come with it.

 

2 hours ago, Guy_Smith said:

Are there any performance issues in eliminating the redundant TOs?

Probably. These things are difficult to measure.

[Guy_Smith]

Thanks for the responses, gentlemen.  If you don't mind me pressing the point a bit more, comment's remark " There is a convention to place the parent on the left and child on the right. " is what got me into this mess in the first place:  In studying the 04_Bonsai Relationship Graph, I started moving the TOs around to get the standard parent on the left and child on the right format when i noticed that i could rearrange the graph to have three identical copies of  ORDER --< LINEITEM >--PRODUCT, just with different names and Without changing the Context.  I would still be looking at the same PRODUCT Table from the same ORDER Table through the same LINEITEM Table?  I understand this may not be the case for grandchild/great-grandchild TOs as the context could get tricky.

As long as I re-link all fields in the layouts using the pink and green sets in the Relationship graph to the corresponding TO on the purple set, why can't I just toss the pink and green sets into the trash and use the purple set by itself?  Or to better ask the real question "If I set it up initially with only the purple set and link all of the fields correctly to begin with, will the solution still work as expected and with a lot less clutter?"

Thanks again and I look forward to reading your responses.

Sincerely,

Guy

[comment]

Basically, you are asking why use the Anchor/Buoy model. I am not the right person to answer this, since I am not a proponent of the model and I do not encourage people to use it.

However, you do need to understand the Anchor/Buoy model before accepting or rejecting it. The redundancy that you see is not accidental or a by-product of the method; it is the method itself.

 

--
Thoroughly recommended read: http://www.nightwingenterprises.com/Resources/approaches_to_graph_modeling_en.pdf

 

Edited July 26, 2016 by comment

[Guy_Smith]

Thanks very much for the link, comment!  I'm used to twelve steps, so a mere 9 ought to be a piece of cake 

May I assume you prefer Selector/Connector?

[Guy_Smith]

Comment:  Thanks very much for the link to Ray Cologon's outstanding article on graph modeling.  Your characterization of the TO redundancy in anchor-buoy model being the model itself really made sense to me after reading the article.  As scary as it sounds, I think that I'm actually starting to understand the finer points of how the Relationships Graph works.

Thanks again for your guidance and enjoy your day!

Best Regards,

Guy

[Wim Decorte]

the best introduction to anchor/buoy is here: http://kevinfrank.com/anchor-buoy/

 

[Guy_Smith]

Wim: Thanks very much for the link.  Interestingly, the Kevin Frank & Associates website states   "Note: These legacy materials are more than ten years old, and are provided as a service to the FileMaker community. We no longer use, or advocate using, the Anchor/Buoy technique."

I've now gotten a thumbs down from both KF&A and comment about using Anchor-Buoy:  For a relatively simple solution (a dozen tables and a max of a few thousand total records), what graph model would you choose?

[webko]

If _you're_ comfortable with Anchor/Buoy, then use that - in many ways, the approach that conceptually works for the database designer is the best... 

And for a smallish system, the overhead from redundant TOs is not a major issue.

 

[Wim Decorte]

4 hours ago, Guy_Smith said:

Wim: Thanks very much for the link.  Interestingly, the Kevin Frank & Associates website states   "Note: These legacy materials are more than ten years old, and are provided as a service to the FileMaker community. We no longer use, or advocate using, the Anchor/Buoy technique."

I've now gotten a thumbs down from both KF&A and comment about using Anchor-Buoy:  For a relatively simple solution (a dozen tables and a max of a few thousand total records), what graph model would you choose?

 

You should use what you are comfortable with.  A/B works well even with very complex solutions.  We use it extensively at Soliant because it is a simple model to grasp so it makes it accessible for all level of developers.  Easy to teach, easy to apply, easy to troubleshoot.

There is a lot of personal preference involved for a lot of developers so don't take any thumbs down or thumbs as anything but that.  Try a few and see which one resonates the  most with you but give it some time.  If you pick up a solution in a few months that you have not worked on: can you still make sense of it?  Can you easily troubleshoot context issues?

 

 

 

 

[Guy_Smith]

Hmmm... After evaluating my true abilities at database design, the model that best matches my talents is the Amorphous/Chaotic concept!  Now that I understand the rationale behind the duplication in the A/B model, i will probably continue with that for my current project, but am looking forward to exploring other methods as I gain more familiarity with FMPro.

Thanks again to all of you for your insights.

Best Regards,

Guy