1 2 3 Previous Next 35 Replies Latest reply on Oct 30, 2015 5:36 AM by ninja

    Unifiers Unite!


      Several years ago I switched to a Unified graph method based on tests that Mark Richman of Skeleton Key did for WAN performance.  In truth, I don’t know how much faster my solutions are then they would be had I used Anchor-Buoy.  But I’ve grown to like the method.


      I’m curious who else is using the Unified method and what your Relationship Graph looks like so I invite you to attach a screenshot of your Relationship Graph.  Attached is an example of one of my solutions.

        • 1. Re: Unifiers Unite!

          Daniel -


          I use something akin to the unified model (although trending more towards the satellite in many cases). I've never really liked Anchor-Buoy (yes, I know that makes me a heretic) for a number of reasons. See attached for a partial.


          Screen Shot 2015-10-16 at 8.25.03 AM.png

          • 2. Re: Unifiers Unite!

            FWIW, I've adopted a "Functional TOG" method.


            The benefit of this is that when a different person comes in to manage the dbase, they can quickly identify what TOG they should be working in based on the business process they are looking at.


            The overall relationship graph is much larger, but segmented into functions making the one you want to work on easier to find.


            Functional TOG.png

            I haven't come across a downside yet...except maybe for that cross-link in the middle where I got lazy.

            • 3. Re: Unifiers Unite!

              Here is mine, I don't know how to call it.


              BasicTutorial 2015-10-16 at 11.10.49 AM.png

              • 4. Re: Unifiers Unite!

                Thanks Mike, Eric, and Ibrahim.


                Ibrahim, I think yours is an Anchor-Buoy model.  It is very organized and easy to read.

                • 5. Re: Unifiers Unite!

                  Hi Daniel


                  I used to call it "the squid army" .

                  • 6. Re: Unifiers Unite!

                    Looks pretty much the same as my approach. It helps a lot when functional  isolation of processes is mandatory - i.g.  if one seeks approval for the solution for use in a regulated environment.

                    • 7. Re: Unifiers Unite!

                      FWIW, one of the features of a unified system is that a layout can be based on a table occurrence that is within the midst of the graph.  In other words, not only the "head" as in Anchor-Buoy/Squid.


                      Here is the same image I posted before but with some internal table occurrences highlighted.  UI layouts are built upon these.


                      Unified Graph_layouts.png

                      • 8. Re: Unifiers Unite!

                        Yes, exactly. It preserves the bi-directionality of the Graph.

                        • 9. Re: Unifiers Unite!

                          Is there more documentation, blogs, etc. related to this that someone could point me to? I'm using anchor/buoy almost exclusively, but I'm not a zealot, and I'd like to know more about this alternative approach.


                          Chris Cain


                          • 10. Re: Unifiers Unite!

                            Hi Chris,


                            I haven't read/seen too much on this other than Mark Richman's interview, linked in the original post.  Anchor-buoy is far and away the most popular model and I know some devs who use a Session model.  But I rarely hear of people advocating for a Unified method which is why I started this post.  I was sure there are others who used it (I'm not that original) and I wanted to hear from them.


                            I think Eric's method is pretty interesting as it seems to be a cross between Anchor-Buoy and Unified.  I suspect there are several variations on this theme.

                            • 11. Re: Unifiers Unite!

                              Yes, exactly. It preserves the bi-directionality of the Graph.


                              Right Mike!  I love that I can take a join table and just paste it on the layout based on the other parent table!

                              • 12. Re: Unifiers Unite!

                                I use whatever works best and makes the most sense to me. I name my tables occurrences in ways that makes sense to me and have a logical flow. They look somewhat like anchor-buoys, but the anchors are really a global table that I change fields in so I can have multiple lists on the same table. I also keep a set of utility tables at the top that are not inter-related. This way I can script the way a record is a created down to the letter.


                                I learned originally on FM, but have spent the last several years working with SQL variants, so I join my tables in the way I would join a query to show the data I would like to show.  If that makes sense.



                                The biggest thing that matters to me is that the other programmer here can make sense of my relational graphs and my code.


                                I have the same tables on my graph a ton of times though:

                                I don't know that its the right practice or not, but because I use say the additional details table and attach it to vendors, items, orders, etc I am able to re-use the table and increase its value to me.

                                • 13. Re: Unifiers Unite!

                                  Hi Daniel and All,

                                  Here is the relevant portion of the video: https://youtu.be/CxUWUFsdLnU?t=3m28s

                                  There are many factors that would go into a comprehensive comparison of anchor-buoy vs. unified.

                                  The data that is moved over the wire is of different types that vary in proportion, system to system.

                                  Here are some of the factors that will affect the relative speed:

                                  • The size and shape of the Relationship Graph(s)
                                  • The proportion of record data vs. other non-record type data

                                  In setting up a test suite you could set up different scenarios with different proportions of type of data and would get different results.

                                  There is more work to be done in benchmarking different approaches to managing the relationship graph!

                                  You would then want to balance the results from a real world based, comprehensive test suite against a variety of other factors.

                                  • How well does each Relationship Graph method scale?
                                  • Is the performance different meaningful or theoretical?
                                  • As a single TOG grows what is the impact on performance? Factorial math impacts?

                                  Those are my thoughts for now.

                                  • 14. Re: Unifiers Unite!

                                    I tend to like and use what Ray Cologon calls a "hybrid" model, which preserves the bi-directionality of the relationship graph and helps keep down the number of TO's. His paper on the topic is an excellent read.



                                    1 2 3 Previous Next