Jump to content
Sign in to follow this  

Question(s) about Relationship, TO Strategies

Recommended Posts

I am at a crossroads in my development of a database.

I began experimenting with the anchor-buoy strategy because the elegance of the layout-based approach appealed to me.

But now I am realizing that this may not be the best solution for my database goals (and perhaps not as elegant as I thought it was).

I hate to redesign the relationship graph but I'd hate even more to redesign it at a later date when my database has grown even more.

If I understand correctly, the Anchor-Buoy approach encourages only the Anchor TO to possess a layout, while the other TOs support the the Anchor TO with related data. Again, if I understand correctly, having layouts in the supporting TO is highly discouraged.

However, I am realizing that I wish I had layouts in the "Buoy TOs", and thus my dilemma at this time.

First Question: do I have an incorrect understanding about this practice of the Anchor-Buoy approach?

Is there any harm in creating layouts for the Buoy TOs?

Second Question: Are there better solutions/approaches to the TO graph? ( I know that this really depends on the needs of the database; but I thought this might begin some discussion, so that I can understand the strengths and weaknesses of different approaches).

I am realizing that much of my database follows a "narrative", that this layout will naturally follow a certain layout. And this jumping around to different Anchor-Buoy groupings to bring up the desired layout is causing me some concern.

I would appreciate any insight into this issue. Also please understand, my understanding of FM is still at the novice stage, and many of my assumptions might be wrong!

Share this post

Link to post
Share on other sites

It really does depend on the situation and preference. For example, if building solutions for an in house developer, I think anchor buoy is the best way to go since its IMHO its the easiest for outside developers to pick up from if one end up leaving or if there are multiple.

However with some vertical solutions it may be more beneficial to use a different graph model.

Here is a link to an older post that discusses the same topic. To read Ray's paper on graph modeling, I think you have to be a technet member which I think is free now for the white paper access.


Updated link to TechNet Whitepaper


  • Like 1

Share this post

Link to post
Share on other sites

Thank you mr_vodka,

I think those links give me a good start to understanding the tradeoffs off the different approaches...

Share this post

Link to post
Share on other sites

There was a session regarding this subject at DevCon this year that I would really have liket to attend. Unfortunately I wan't able to attend DevCon at all. I wonder if anyone around here made it to that session.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  


Important Information

By using this site, you agree to our Terms of Use.