Database Reference
In-Depth Information
However, FileMaker has two commonly used graph arrangement models: spiders and an-
chor/buoys. Both have their strengths and weaknesses. Spider graphs are simpler, because
you can use relationship bidirectionality to use each TO for several different purposes. This
technique tends to keep the need for extra TOs to a minimum. Anchor/buoy graphs are easier
to understand, but you give up the flexibility of bidirectional relationships in return for legib-
ility. Plus you'll end up creating two or three times as many TOs as a spider graph.
The first arrangement of TOs you made (the one that looks like an ER diagram), is some-
times called a
spider
because there's often a central table occurrence from which most other
TOs are connected. If you're adopting this model, you may decide to keep the central spider
free of extra TOs and then create free-floating TOGs whenever you need new relationships
between tables.
NOTE
There's no one-size-fits-all rule for graph arrangement, but there are general rules of thumb. Plus,
you can adapt formal data models to handle time-tested processes like inventory control or student
registration databases. Those concepts are complex, though, and beyond the scope of this topic. Do
a Google search for
data modeling
to find out more, but don't get too bogged down in theory. As
you already know, FileMaker is easier to use than most any other database out there, so some of
those concepts won't apply to your FileMaker solutions.
Anchor/buoy graphs also get their name from their appearance. The second TOG you created
(
Creating a New Table Occurrence Group
)
is an anchor/buoy TOG. That is, the TO on the
left end of the group provides the context for the TOG's layout. All the other TOs flow out to
the right in lines (or buoys) that are “anchored” by the main TO. Because these lines can be
three or more TOs long, they can start to look like tentacles, which is why some folks call
these graph arrangements
squids
instead. Since a layout's context almost always comes from
the anchor in a TOG, there's no ambiguity about which TO to use. And calculations are easi-
er to write because the TOGs are rigidly arranged. New developers find that this predictabil-
ity helps them get up and running more quickly.
Some developers always work with one of these models, and asking them to consider change
is like starting a discussion on politics or religion. If you're interested, search the Web for
anchor-buoy, FileMaker data model
, or
FileMaker Relationships graph
. If you join
FileMaker's TechNet (
Developer Programs
)
, you'll get access to white papers, including one
on the pros and cons of several different graph arrangement schemes for FileMaker. With
time and experience, you'll find that some databases work better with one arrangement, but
others work just as well with a hybrid of spider and anchor-buoy (
Figure 14-17
), or another
arrangement.
