There are many different ways of building the RG. Ray Cologon has them catalouged in his white paper which is, in my opinion, required reading if you want to discuss the pros and cons of any style.
It is in the Technical Briefs and White Papers section with the title "Approaches to Graph Modeling"
You'll likely want to pore over his paper both before and after you hear his presention to next month's DevCon!
Oh yes, things get very complicated. In the past if we even had one place where we needed to set the context to another table, we had to add it to the relationship graph. What is nice in version 12 is if you only need it once and it can be displayed by a SQL call, you can do that with the Execute SQL instruction and this may minimize the amount of table occurrences we need since SQL steps can set their own context independent of the layout. Here is the current database I am working on, but as a developer, I work on lots of different databases.
Yes, things can get complicated. While the RG may look cluttered, it's important that a developer be able to make sense of it when working on future modifications. Sometimes there may be an existing relationship that gets what you want, but it's more important to maintain the perspective/context of where you are in the system.
Here's one of our products that was highly modified. Low res to protect client.
And I thought my Relationship Graphs are a mess; thanks, you made my day!
I had some deeply philosophical thoughts about the RG I wanted to share, but Ray Cologon can't be beat!
Does someone know why he hasn't written an FM 11 Bible?
PS: Here's another one:
NeatGraph.png 319.5 K
Take a look at dbmike's graph... it looks like he is using Anchor Buoy system which is a good way optimize FileMaker so that any given layout is only thinking about what it has to and not thinking about a bunch of unused table occurrences. It has some disadvantages too, but if you need to improve performance, it sure can help.
Yes, we use anchor buoy. This particular implementation strayed a little bit (another developer had joined anchors). I'm relatively new to FileMaker and it took me a little while to appreciate the benefits of anchor buoy. Working in a development shop with multiple programmers, it is far easier to understand the intent of another developer in anchor buoy, as well as far easier to modify a particular relationship without damaging other aspects of the solution, especially with a modular setup. Even though we use anchor buoy, I need to read Ray's white paper to learn some.
I really wish I knew about FileMaker years ago!
Very messy sometimes. PaperCutPro, my paperless medical records/practice management solution started in 2000 to simply record vaccines and generate the required school vaccine records that my office had to supply to parents. Now it does everything, and I mean everything! (http://www.papercutpro.com) So it is very complex. I had to reduce my graph from 2500+ wide X 1400+ tall to 450 wide.
PaperCutPro, a complete paperless medical records solution
83 tables with 1 primary database and 3 accessory databases
60 custom functions
104 custom menus
Clones total 33+megs
Thanks all. (I was at Prometheus. It was pretty good!)
Thanks for the shots of your graphs. It makes me feel okay that my RG is gettin a bit complicated.