For it to work I have to master using global variables (and executeSQL) to switch contexts / layouts. True?
Care to name a source for this outlandish idea?
The anchor/buoy methodology is probably as old as FileMaker 7 and the Relationship Graph itself (which is exactly 10 years), and thus older by some years than both of these features (at least in FileMaker); still, people managed to use FM and anchor/buoy without them.
Also, neither would let you “switch contexts/layouts”; correct is that both work (more or less) independently of context. Open any programming textbook and read up on the (mis)use of global variables.
Rather, strive to master context and its implications throughout a database and its tables. You will need that regardless of how you arrange your TOs.
- For future development. Eaiser for other to understand and get stuck into
- Efficient. Database looks up the relationship it need to as opposed to chewing through a web of relationships
There are other methodologies that don't require you to connect everything to everything else (aka “The Web of Death”). Anchor/buoy is its strictest form is inefficient in that it requires you to add TOs wherever you need to lookup data from parent tables; as an alternative, define a TOG that models your pure structure, and define calc fields in FM6 pass-through style. Well, those were the days …
Does anyone have any good papers on the subject for my level?
There's a White Paper by Ray Cologon on Relationship Graph Methodologies; search the FM knowledge base. It's the best and most comprehensive treatise on that subject, so I wouldn't worry too much about any 'levels'. (And its as deadpan as the subject could possibly allow.)
My first FM databse is my end objective and it is a large work
Why not start with something small and simple, or do it in parallel to experiment and test new concepts? Knowing your data and the expected outcomes may be of help, but this still leaves you with the attempt to implement a (presumably) complex system with a totally new tool.
so I don't want to look back at it in 5 years and go WTF!
You will; we all have. Whatever outlook you have in 5 years time will make your current efforts look amateurish. (And who knows where the FM platform stands 5 years from now).
have read the 13 advanced manual a couple of times
You know what they say about how to get to Carnegie Hall? (very old joke)
Thanks for the reply!
I have noted your points . I will do more work on context and get back to what I want the solution to do and revist the ERD. I note what you say about not taking on the monster solution first (well monster to me anyway with 20 tables in the first stage). It was in the back of my mind.. ( that solutoin planning still needs work) . too much while learnign as you say . I may get a developer who is willing to coach a bit with fastrack of learning and the solution to market in mind
Early in my learnings (yesterday) I had somehow got it in my head that each layout would be based on a different table occurance group. shaking that one loose has cleared some fog
Thanks for that too. Dowloaded and reading
You have to look at the goals of Anchor Bouy, which was to minize the number of relationships to a layout with context set by the table occurrence. Since FileMaker has to think through all these relationships, minimizing the number of relationships it needs to think through for a given context and layout can make FileMaker perform better. At least that seemed to be the primary goal from people I worked with that were using it. But it forced you to create a whole new relationship graph for each table occurrence/layout and this can make the number of table occurrence become huge and naming convetions challenging for them.
Anchor Bouy does still have its places when trying to optmize a particularly slow layout. However, it was a tool primarily developed before the advent of tools like ExecuteSQL which can completely bypass the relationship graph.
Now I spend more time minimizing my relationship graph and its complexity by reducing any relationship unless it is going to be used more than once (e.g., multiple calcluations, portals, etc.). All singel relationships I simply use SQL to make the context and find the answer. And in scripting, you can have the SQL performed on the server and make things go a lot faster. So I find myself using SQL and Perform on Server in virtual arrays as performance enhancers for reports. This returns better performance than arranging everything in the anchor bouy arrangement.
I will not dismiss anchor bouy method, but it is not a primary development tool for me anymore particularly in regards to optimization and performance improvements.
One thing Anchor Bouy did do was force people to get better organized in the relationship graph. And this is something I think many of us need to do a better job of in development. Organization, commenting, use of colors all are tools to help better organize the schema and make it easier for future developers that might have to figure out what we originallly created.
Thanks Taylor .. I figured my years of dodging sql competancy were at an end .. Just bought an SQL book as well . oh boy!
I want to chime in here to give you a different perspective. I think A/B is a fabulously helpful method, and I use no other any more (although I do make slight modifications when necessary). When FileMaker 7 came out, it wasn't long before I was in a quagmire of TOs (Table Occurrences) with names that meant nothing to me. I began to dread returning to the graph when it came time to add new features or debug the earlier ones. It was even worse when I would need to select TOs from various drop-down menus. Names for TOs that had meant something to me at the time I created them turned to useless gibberish in as little as a few minutes — even when they included the name of the base table.
One of the commentators on this post seemed to indicate that you might need a separate relationship for every layout. (Probably just a misunderstanding on my part, but I didn't want you to misunderstand either.) That is not the case. I have many layouts all using the same relationship.
I'd like to send you a chapter from one of my Learn FileMaker Pro books from a few years ago. You can email me at JStars@DataDesignPros.com. Beyond that I highly recommend going to www.kevinfrank.com/anchor-buoy.html. Kevin Frank did a great job on these presentations. I suggest the long version of the PowerPoint. It may not clear up everything for you, but it's a great reference.
Granted, there are a few limitations to the method. However, you can build your database using the method and then break away from it on the few occasions where it doesn't work. (One example is when you want all or most tables to refer to a reference table.) But that's all another story.
hammer, your SQL book may help, but maybe not with ExecuteSQL() implementation in FileMaker. There was little documentation on that, so I wrote one.
I pretty much pounded through testing a bunch of SQL that would be used in MS SQL, Oracle & MySQL. They can have different functions, BTW. So the 'refererence' is about what works (and what doesn't) in FileMaker with ExecuteSQL (the function, not the script step). There are a few new calls that can be used with FM13, so check this out
If, however you plan to use FM as an ODBC source, or connect FM to one of the SQL dbs, then your book may be helpful to understand SQL.
My guide also points to several articles, blogs, plug-ins and examples using SQL with FM. Here's an updated link for SQLExplorer <http://www.seedcode.com/new-sqlexplorer/>
Remember also that one of the chief limitations of A-B is that it breaks the bidirectionality of the Relationships Graph. By its very nature, A-B is monodirectional; it starts with a base table occurrence for each table and flows from there. So, you lose one of the biggest advantages of moving from the pre-7 paradigm (the relationships list) to the Graph.
The Relationships Graph is something that looks like an entity-relationship diagram, but isn't one. A-B just exaggerates the difference (which, IMHO, isn't necessarily a good thing).
Thanks for making me aware of your work! That is going to save me much pain!
Well my eyes remain open. I had read the Kevin frank presentation. I feel the white paper above is more helpful and balanced and perhaps presents methods which have evolved since.
I see what you are saying and I will try and apply a/b for a while.
I will email you for your other book pages. Thanks
I don't suppose you have a simple example of a scenario where bidirectional limitations present themselves. Or an example of a beneficial bidirectional relationship scenario you have used?
Sure. Let's take a fairly common example, where you have something like this:
Invoice --< LineItem -- Product
If I just use a standard Relationship Graph, it's exactly three TOs. If I want to know anything about any product from any invoice, I can do it from Invoice and I know it's in Product. If I want anything about any invoice from Product, I know it's in Invoice. Or if I want anything in either Product or Invoice from any line item, it's in Product or Invoice.
On the other hand, with A-B, it looks something like this:
Invoice --< LineItemInvoice -- ProductInvoice
LineItem >-- InvoiceLineItem
Product -- LineItemProduct >-- InvoiceProduct
Now, I've massively complicated my life. In order for me to get from point A to point B, I have to make sure I pick the right A and the right B. I can't just say, "Go from Invoice to Product." I have to say, "Go from Invoice to the Product that is attached to Invoice, which I've named ProductInvoice."
So I either have to give up on the bidirectional nature of the relationships, or I have to jump around to a bunch of layouts that are coded to the various child TOs in the A-B model. Which A-B isn't really meant to do. (You're intended to start with the parent TO and flow to the right to get where you want to go.)
There are a couple of reasons why A-B became popular. One was it was one of the first really structured ways to deal with the Graph (which, let's face it, we really needed; everyone's seen those horrible chaotic spiderwebs). The other was that it was comfortable for folks who we're making the transition to the post-Relationships Graph world from the relationships list world (where your starting point was always the current file). A-B mimics the pre-7 world in that each starting TO and its attendant chain correspond to what would have been the relationship list for a single file. This makes it handy for people who were trying to get used to the post-7 paradigm.
However, IMHO, the downsides of A-B aren't worth the benefits. As Dr. Cologon's white paper demonstrates, there are other options for achieving good graph organization without losing the benefits of bidirectionality or adding lots and lots of TOs to your graph. Plus, those extra TOs require layouts for scripting, which also adds time.
I know there are plenty of folks who are hardcore A-B fans. And that's great. I just don't care for it myself.
This is not entirely correct, Mike. One of the most important "rules" of A/B is the naming of Table Occurrences. If we look at your example, naming might work like this:
Table Table Occurrence Name
In your first example, the names might look something like this:
INV --< inv_ILI__InvID -- inv_ili_PRO__ProdID
I'm not sure about the other relationship examples because your naming method doesn't make it clear enough for me to speculate.
Each TO name tells me where it lies in the graph and (approximately) how they're joined. (InvID means the first two tables are joined by InvoiceID at least in one of the tables.). And it's also very convenient to know what tables you're looking for in the various drop-down menus throughout the file.
You are correct that the graph does grow. But I can come back to a file I created years ago and know right where I am. Before I adopted A/B, I could easily find myself lost in as little as a few minutes. The naming convention is perhaps the most beneficial part of A/B.
Regarding overhead, I'm working with a huge file I consolidated from 75 files created by an amateur client pre-FMP7. With all the back and forth relationships, it all works quickly and smoothly for the hundreds of users.
One hint is to keep a Legend in the graph that tells you what each abbreviation stands for.