There was a decent DevCon session that compared three different methods--including Anchor Buoy and Selector Connector. Interested parties may want to look up the presentation materials on it. One key conclusion that I took away from that presentation is that while there can be performance costs for having a large, complex relationship graph, such a "hit" tends to be a very small fraction of the total time needed to present a user with data on a layout.
When I read the above blog, I find that he really hasn't, in my opinion, strayed far from Anchor Buoy in his current methods. He seems to have just added a few connections between TOG's and not restricted himself to a formal A/B "tree" with the anchor on the far left. This produces sort of an A/B approach without getting legalistic about how you organize the TO's
What I've found missing from many discussions of how to do your relationship graph is the simple observation that, regardless of whether or not you use A/B, you will be doing a nice thing for yourself and any fellow developers if you break up your graph into logical, manageable TOG's. Nothing gives me a bigger headache than opening up Manage | database and finding a massive single group of relationships and then having to plod through them all looking or the 2 or 3 relevant to the script or calculation that I am analyzing in order to correct or otherwise modify. The fact that they might be organized into a typical "Tree" resembling A/B, doesn't really help at all.
I refer back to this PDF by Dr. Ray Cologon:
I see your point, phil (and Kevin's original reasoning). The A-B let you "group" tasks based on the 'Anchor' (or at least that was my perspective!)
This was my comment (on the 'Life After...' blog):
Yes A/B was important for the paradigm shift from the old relationship "list" to the new relationship "graph". Even SQL-mavens used A/B to make it clear what each anchor did and all the buoys that needed to connect to it, even if "redundant".
With the introduction of ExecuteSQL(), some of the buoys simply could go away. Especially those that had to have a constant of some kind to make a relationship work. Add filtered portals and toss out a few more of those buoys!!
Do you think without eSQL and filtering that it would have been as easy to shift back to more ERD-like RG's?
Kevin answered with:
Even without eSQL and filtered portals I would have made the transition. I believe they had zero impact on my decision.
So my shift from so much A-B is the ExecuteSQL() and filtered portals. But I still go back to Ray's PDF. There are many ways to RG (relationship graph) and his points should all be considered for the reason's he states. There is a reason to use a combination, sometimes.
1 of 1 people found this helpful
My point was that whether you use A/B or some other methodology, Make your data model Modular to save developers time when they need to analyze that data model. I don't see much point in shaving milliseconds off the time it takes to open the file and present data to the user if it costs the developer half an hour spent wading through a large monolithic data model in order to fix a bug or add a new feature.
So use a formal A/B, use Selector connector, use a modified a/B format as presented here, or spin up your own just be sure to:
a) be consistent to your rules (including naming conventions) and document them.
b) be modular where possible to keep the total number of TO's in a given group as small as possible
1 of 1 people found this helpful
A nice discussion exists here regarding the unified graph method: Unifiers Unite!
I wasn't at DevCon, but would have loved to attend that session. I thought Kevin's article was insightful, as always.