algae bloom of table instances on my relationship graph

I am intermediate FMP developer in XP. I am developing a system for a
large membership association. They have a fairly complex business.

what I am finding is I am having to create more and more instances of
tables in the relationship graph, and I am beginning to wonder if
there is not a best practice that I could implement such that this
would be minimized.

For example, I have a global table with things like graphic elements
and temporary fields. When I create a new table, and I link it to the
global table, filemaker is wanting to create a new instance of the
table. Of course this creates a problem cuz my graphics for buttons
and what not do not display, and I have to reset the container field
for the graphic to the new instance of the global table.

End result is my relationship graph is getting unweildy.

Any tips from you veterans out there?

Darren

Re: algae bloom of table instances on my relationship graph

Addendum

So actually what I discovered is that layouts that are associated with
tables that are remote to the global table (with the graphic
components) do not show the graphics until they have actual records in
a join table that is one step closer to the global table.

So the relationship path is there, but it does not get activated until
data is present in a intervening join table.

Is there a way around this? I want the global graphics to show up no
matter if there is data or not in the join table.

darren

Re: algae bloom of table instances on my relationship graph

On 2007-09-20 12:29:10 -0700, Darren said:

> I am intermediate FMP developer in XP. I am developing a system for a
> large membership association. They have a fairly complex business.
>
> what I am finding is I am having to create more and more instances of
> tables in the relationship graph, and I am beginning to wonder if
> there is not a best practice that I could implement such that this
> would be minimized.
>
> For example, I have a global table with things like graphic elements
> and temporary fields. When I create a new table, and I link it to the
> global table, filemaker is wanting to create a new instance of the
> table. Of course this creates a problem cuz my graphics for buttons
> and what not do not display, and I have to reset the container field
> for the graphic to the new instance of the global table.
>
> End result is my relationship graph is getting unweildy.
>
> Any tips from you veterans out there?

One approach is to use "Anchor-Buoy" (sometimes called the "squid" ), a
system for arranging table occurences and nomenclature that makes it
easier to manage the graph.

See http://www.kevinfrank.com/anchor-buoy.html for information on this.
Also do a google search for anchor-buoy.

Basically, every layout gets an anchor, and all downstream buoys
necessary to access related data FROM THAT LAYOUT are created as
needed. This means there are a lot of duplicate TOs, but the naming
conventions make it easy to manage. Unless you start getting into
thousands of TOs, there is little overhead in having many TOs in the
graph. And then the only performance hit I've found is in closing the
graph dialog. Launching and performance of files is unaffected.



--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA

Re: algae bloom of table instances on my relationship graph

On Sep 20, 10:58 pm, Darren wrote:
> Addendum
>
> So actually what I discovered is that layouts that are associated with
> tables that are remote to the global table (with the graphic
> components) do not show the graphics until they have actual records in
> a join table that is one step closer to the global table.
>
> So the relationship path is there, but it does not get activated until
> data is present in a intervening join table.
>
> Is there a way around this? I want the global graphics to show up no
> matter if there is data or not in the join table.
>
> darren

A field with global storage can be referenced from any table. You do
NOT need to relate a table to another in order to access global
fields. It's one of their critical features.

And for the relationships you do need, I also recommend Anchor Buoy as
a good starting point. It's the number of TOs that you need to worry
about, it's keeping them well organized and A-B is very helpful in
doing that.

G

Re: algae bloom of table instances on my relationship graph

Thank you for the replies!

A few more questions

1. does anyone have a small sample file using the AB approach? I
looked on Kevin's site and I have see the PDF's and mindmaps. A
sample file would help.
2. If I convert my existing spagetti style relationship graph to
Achor Buoy, will it break my scripts, calculations and layouts?

Darren

On Sep 20, 5:51 pm, Grip wrote:
> On Sep 20, 10:58 pm, Darren wrote:
>
> > Addendum
>
> > So actually what I discovered is that layouts that are associated with
> > tables that are remote to the global table (with the graphic
> > components) do not show the graphics until they have actual records in
> > a join table that is one step closer to the global table.
>
> > So the relationship path is there, but it does not get activated until
> > data is present in a intervening join table.
>
> > Is there a way around this? I want the global graphics to show up no
> > matter if there is data or not in the join table.
>
> > darren
>
> A field with global storage can be referenced from any table. You do
> NOT need to relate a table to another in order to access global
> fields. It's one of their critical features.
>
> And for the relationships you do need, I also recommendAnchorBuoy as
> a good starting point. It's the number of TOs that you need to worry
> about, it's keeping them well organized and A-B is very helpful in
> doing that.
>
> G

Re: algae bloom of table instances on my relationship graph

On Sep 20, 11:51 pm, Grip wrote:
> On Sep 20, 10:58 pm, Darren wrote:
>
> > Addendum
>
> > So actually what I discovered is that layouts that are associated with
> > tables that are remote to the global table (with the graphic
> > components) do not show the graphics until they have actual records in
> > a join table that is one step closer to the global table.
>
> > So the relationship path is there, but it does not get activated until
> > data is present in a intervening join table.
>
> > Is there a way around this? I want the global graphics to show up no
> > matter if there is data or not in the join table.
>
> > darren
>
> A field with global storage can be referenced from any table. You do
> NOT need to relate a table to another in order to access global
> fields. It's one of their critical features.
>
> And for the relationships you do need, I also recommend Anchor Buoy as
> a good starting point. It's the number of TOs that you need to worry
> about, it's keeping them well organized and A-B is very helpful in
> doing that.
>
> G

I'm slightly ashamed to admit I use Google Groups for my Usenet
postings. Yes, I know I need a real newsreader. There seems to be
some problems lately with posts missing and Darren's reply is
missing. If someone would be so kind to repost it, I'd appreciate it.

Thanks,
G

Re: algae bloom of table instances on my relationship graph

On Sep 20, 12:29 pm, Darren wrote:

> End result is my relationship graph is getting unweildy.
>
> Any tips from you veterans out there?

I went through this same struggle when FM7 came out, and there were no
great solutions then, and there are no ideal solutions now.

The best place to start, I think is:

http://www.filemaker.com/downloads/pdf/FMDev_ConvNov05.pdf

It covers 3 methods, including the A-B method a few people here have
suggested.

Note # 1 - the above is not gospel. Its good advice, and a good
starting point, but a good developer will do what works for them,
taking the parts they like, etc.

Note # 2- The 'spider', the first method they cover you don't want to
touch with a 10 foot pole. Its probably very nearly what you've got
now. And there is a reason you are complaining about it! Its ok for
very small databases though.

Frankly, I don't like strict A-B. I like that it is easy to
understand, easy to do, and I agree that it is organized. Its probably
the easiest to do on 'auto-pilot' because you don't really have to
make decisions about how best to build the graphs.

However the rigid left-right interpretation of the relationship graph
i find needless and irksome, even asinine.

The big problem is that it has a tendancy to cause too much
functionality to be anchored off one buoy.

Although HTOG (aka A-B, aka squid) and FTOG (using the names in the
document defined above) are described as separate methodologies, they
are actually completely independant, and you could in theory use both
simultaneously: FTOG to define your function groups, and HTOG to build
trees within each Function group for example.

Personally, I lean more to the FTOG side of things; but I've
incorporated some of the A-B stuff to overcome its shortcomings.

For example it lists among the pros of FTOG:

"Can work with large solutions with the caveat that it's dependent
upon the number of functional needs. The more functional needs the
less attractive it becomes."

But the reality is that A-B fares no better in this case. And if
anything, while an FTOG chart becomes ever bigger it doesn't become
convoluted or complicated.

An A-B system becomes unmaintainable because individual anchor layouts
are now hosting dozens of independant functions all mixed together, so
the buoys for all those unreated functions are all in one tree,
potentially being re-used for independant functions or duplicated
redundantly, etc. You become afraid to change anything because there's
no easy way to tell what other function might be affected in a
functionally-dense A-B system - and so you just keep adding new buoys
to play it safe, which just compounds the problem.

It lists also among the cons:
"Naming does not attempt to expose structure or meaning outside of the
graph."

If that's something you want, its easy to add, and is hardly an
inherent limitation of the methodology.

The biggest con to FTOG vs A-B is that its not as "automatic". The
developer has to think about what the function groups are, and limit
them. If you aren't disciplined you might put multiple functions into
a single group and undermine the methodologies usefulness, or get
overly anal and break a single simple function into pieces which are
needlessly small. A certain amount of 'reasonableness' is required,
and that takes some practice and common sense.

Anyhow that all re-iterates my point; take a look at the design
methodologies and take what you want from it. I doubt anyone thinks
any of them is perfect.

cheers,
Dave

Re: Re: algae bloom of table instances on my relationship graph

Grip, here's Darren's reply as requested.

--
FW


[quote]

Thank you for the replies!

A few more questions

1. does anyone have a small sample file using the AB approach? I
looked on Kevin's site and I have see the PDF's and mindmaps. A
sample file would help.
2. If I convert my existing spagetti style relationship graph to
Achor Buoy, will it break my scripts, calculations and layouts?

Darren

On Sep 20, 5:51 pm, Grip wrote:
> On Sep 20, 10:58 pm, Darren wrote:
>
> > Addendum
>
> > So actually what I discovered is that layouts that are associated with
> > tables that are remote to the global table (with the graphic
> > components) do not show the graphics until they have actual records in
> > a join table that is one step closer to the global table.
>
> > So the relationship path is there, but it does not get activated until
> > data is present in a intervening join table.
>
> > Is there a way around this? I want the global graphics to show up no
> > matter if there is data or not in the join table.
>
> > darren
>
> A field with global storage can be referenced from any table. You do
> NOT need to relate a table to another in order to access global
> fields. It's one of their critical features.
>
> And for the relationships you do need, I also recommendAnchorBuoy as
> a good starting point. It's the number of TOs that you need to worry
> about, it's keeping them well organized and A-B is very helpful in
> doing that.
>
> G

[unquote]

Re: algae bloom of table instances on my relationship graph

> 2. If I convert my existing spagetti style relationship graph to
> Achor Buoy, will it break my scripts, calculations and layouts?

Big time. You'll have to rebase your layouts, resetup most fields on
the layout, update pretty nearly every script reference to a field,
etc, etc, etc.

Its no small task. (This isn't a draw back of A-B per se; any major
design shift where you are moving everything to work with new TO's
experiences this.

I recommend, make a backup, create the new TO structure first, then
updating all the references, then delete the old structure. In that
order.

If you try and re-use parts of the existing structure you'll more
often than not end up confused. If you delete the structure before
remapping it it will be much harder to remap it, as everything will
just say 'unknown field'.

-cheers,
Dave