Hi again,

How can you tell its the weekend, and I'm working on the more
theoretical stuff, instead of the nitty gritty practical stuff.

Ok... so I'm trying to grasp the advantage of HTOG design, (which I
think is the same as the "squid" model) in large projects, especially
when compared to FTOG.

The filemaker development conventions document indicates that HTOG
(Hierarchical Table Occurrence Grouping) is suited for large projects,
while FTOG (Functional Table Occurrence Grouping) is only suited for
small-medium.

I'm not seeing it. I mean, I do see the potential for FTOG to result
in a substantially larger relationship forest, while HTOG is literally
constrained to the number of layouts. So HTOG's graph is potentially
smaller than FTOG, but I don't see it how it could be more
maintainable.

With FTOG, If I am adding a new function, I create a new tree, even if
a suitable layout, and relationship tree already exists. So the graph
grows needlessly, but at the same time I can remove or change
something and be secure in the knowledge that the impact is limited to
that function.

With HTOG its easy to simply expand or reuse TOGs as needed; indeed
that's the point, but I don't see how its possible to safely modify or
remove anything in the graph once its been built, because there is no
way of telling what impact you'll have when deleting it. It could be
referenced *anywhere* in the solution.

So, personally I favor FTOG, it may have a larger graph, but its a
more modular solution, and modular is more maintainable on large
projects, even if the total project ends up being larger.

I can see that FTOG has other disadvantages too. Its much more
semantic, while HTOG is almost 'mechanical'. That makes FTOG more
complex, requiring you to make judgement calls on design while HTOG
doesn't. But that semantic layer that FTOG adds is worth it in my
opinion, as it allows you to really focus on a small isolated problem/
solution instead of constantly being exposed to logically irrelevant
interactions elsewhere in the solution.

Anyone shed some light on why HTOG is thought to be superior for large
projects? What am I missing?

Also, is squid actually the same as HTOG or is it something else?

-regards,
Dave

Many developers are using what has been called the "Anchor/Buoy" method
for organizing the relation graph. Since I'm not familiar with the
terms FTOG or HTOG, I'm not sure which design that A/B most closely
resembles. But A/B is probably as far from a 'squid' design as you can
get. A very good developer named Kevin Frank has put together a
presentation and tutorial on Anchor-Buoy that I highly recommend you
take a look at. He has used these materials to demonstrate the method
for many of the top FileMaker developer groups around the U.S. and more
developers then not have adopted Kevin's methods.

Kevin's site is at http://www.kevinfrank.com/anchor-buoy.html


d-42 wrote:
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Associate Member, FileMaker Solutions Alliance

On Apr 29, 3:13 pm, Howard Schlossberg
<how... (AT) antispahm (DOT) fmprosolutions.com> wrote:
Thanks Howard, actually, HTOG *is* Anchor/Buoy. The FM Developer
Conventions doc actually refers to HTOG as 'also known as Anchor/
Buoy'; so I think we're in good shape.

And now I'm doubly curious what 'squid' is if its absolutely nothing
like HTOG or A/B.

That aside, HTOG is a system where each table in the solution forms
has TO that forms the 'heirarchical head' or 'anchor' of each TOG,
ideally there is only one anchor for each base table, all layouts are
only defined on the Anchors, and any relationship/table occurrence
that is needed by the base table and/or any layouts defined on it) are
attached to that head as 'buoys'. Does that not describe it in a
nutshell?

In the absence of decent standards any standard is a vast
improvement!
FM7/8 is a huge leap from FM3/4/5/6 and a LOT of developers including
myself have been left floundering.
But I'm not a fan of HTOG (A/B); its a good start.

After skimming his slide show (Gad I hate powerpoint!!!) he really
only compares it to FM6, and/or Functional Spiders (which are only
remotely intelligent for small simple solutions.)

And since he's a proponent for HTOG (A/B) he doesn't talk about its
deficiencies at all; specifically he focuses on how it makes building
databases simpler, and more organized, and it does!

But one of A/B's weakness is in maintenance. In a 500 layout solution,
how do I know if I can remove layout X? or script Y? especially if
they perform utility functions. In FTOG you know,

Additionally, he claims that 'related TOs' are relevant TOs but that
is patently false. I suppose they are more relevant than unrelated
TOs, but if you have 2 (or 50) different layouts based on a single
base table and each layout has specialized portal/ relational value
lists, or other 'buoy requirements' you have a long list of irrelevant
'related' TO's to work deal with when working on any given layout/
functional task. In FTOG by contrast the related tables are actually
related to the fuctional task.

He claims as a benefit that 'as in FM6 relationship are only ever
thought of as flowing from left to right', and that TOs list become
analogous to FM6's relationship list. Now how is making it more like
FM6 a benefit? I agree making it more familiar is 'helpful'. But on
some level this is like being handed an adjustable wrench, and
insisting on buying 8 of them all set to different spans, to make them
work more like the old wrench set we used to have. Its simple, its
familiar, its effective, but its not really leveraging the tool.

FTOG shares many of the benefits of HTOG (A/B) in that the
relationship graph and table-occurrence drop downs are controlled,
that 'relevant' design elements are grouped, etc. FTOG is HTOG with
semantics. Because the FTOG trees are small and essentially closed
universes, we can also relax some of the 'think of it like FM6' and
leverage the bi-directionality of relationships, and be more flexible
with layouts on 'buoys' without losing control. But that's optional,
if you wanted to you could almost implement FTOG on right on top of
HTOG (A/B). It would just mean your Functional groups would
potentially consist of 2 or 3 HTOG compliant TOGs where you could have
gotten away with just one TOG if you'd wanted to.

Now please understand that I'm not trying to start a 'holy war' on
design methodologies, I'm open minded enough to recongize we all have
our preferences, and that whats best for me isn't best for the next
person. And I agree 100% that HTOG or A/B is **infinitely** superior
to monstrous spiders, and the out of control stuff we can get
ourselves into if we have no design methodology at all.

HTOG is easy, because it can be applied almost mechanically. But its
not, in my opinon, the best solution.

And I'm interested in cogent arguments for how its superior to FTOG,
particularly in large scale solutions. I want to understand better
relative merits of FTOG vs HTOG (A/B). I'm already amply convinced
that HTOG (a/b) beats a monolithic spider.

best regards,
Dave

There is no "best" way of doing this, and such discussions still persist
between professional developers as to the best method for organizing the
relation graph. It wouldn't hurt FileMaker to provide better
organizational tools in future versions, as the tools for organizing the
graph (not to mention organization of scripts and layouts) are pretty
weak for anything more then a very basic solution.

You've made a lot of good arguments, Dave, against a strict application
of A/B. Since I'm not a strict A/B-ist (for many of the reasons you
raise), I'm going to see if Kevin wants to chime in here.

However, let me take just a quick moment to compare Anchor-Buoy with the
more widely accepted methods used by SQL programmers. (This might have
even more relevance to FMP in the future if you care to read your own
thoughts into the press release at
<http://www.filemaker.com/company/newsroom/releases/1303192.html>.)

A SQL programmer would define 'views' and 'joins' within Select
statements (or elsewhere?) on a case by case basis. There is typically
a primary/base table, as well as only those other related tables that
are relevant to the particular instance that is being defined. You
would typically define a TOG or relation string or view in SQL "on the
fly", and would likely define similar relation strings in multiple
places throughout your solution. If you think about it that way, this
correlates very closely with the HTOG or Anchor-Buoy method in FMP.


d-42 wrote:

On Apr 29, 9:05 pm, Howard Schlossberg
<how... (AT) antispahm (DOT) fmprosolutions.com> wrote:
Agreed. It takes real discipline to keep a large project
comprehenisible; and filemaker does almost nothing to help with the
job.

I think that hits the nail on the head: "Not a strict A/B-ist".

A/B is really a good starting point. Its a simple, almost mechanical
methodology that anyone can apply simply by following the rules. If
you don't know what to do just do A/B and you'll make out ok.

But I think, once you get into it and get the hang of it A/B starts to
fall short.


Here's how and why I think both FTOG and A/B are essentially
equivalent to each other as analogies to SQL views (And how both fall
short in their own way) :

An A/B for table X is analogous to a stored query containing
everything that any part of the database might need when the 'primary/
base table/context' is X.

Now that would only be true of a SQL View if you only used each table
as a base for one purpose. A SQL view for an 'order' might have buoys
for line items, lot numbers, shipping references, for order entry
staff. For the accountant that same 'order' might have buoys for line
items, G/L accounts, payments, etc. In A/B the base TO for orders
would have the buoys to support both functions dangling off of it.

In SQL you wouldn't define your view like that. Sales reps use one
view of orders. Accountants use another. And that is more like FTOGs.

On the other hand, like a SQL view, an A/B contains -only- what is
needed(*) to support working from base table X. An FTOG might be a
little deeper, supporting 'views' from a couple base tables instead of
exactly one. Potentially 'irrelevant' depth can be seen from the
perspective of a given base table as a result. In terms of lining up
with SQL views. An FTOG is a sort of a hybrid stored query supporting
1-3 views, but all related to one function

* Of course, what is needed from base table X for accountants is
different than for sales reps, if you are working on a layout/function
for sales reps you would typically see 'irrelevant' buoys when working
with A/B too.

So it seems to me its a wash. Neither A/B nor FTOG is a perfect match
for SQL views. Both have their pros and cons.

But if you look at how the methodologies cope with scaling up you'll
note that functions and layouts don't tend to get ever more complex,
there just tends to be more of them. FTOGs proliferate to support
this, with each group tending to remain fairly small, while A/B only
proliferates at the likely much slower rate that base tables are
added, but those anchors get ever heavier as more buoys are added to
support new functions.

Whats worse? FTOG with 100 10 branch trees Or A/B with 10 100 branch
trees. One system might have less total TOs than the other in
practice, but I think it really depends on the actual system; I can
think of FTOG scenarios that would require 5x the number relationships
if done as A/B ... and vice versa. Perhaps in actual practice the
total TO's is skewed in favor of A/B ??

I'd think in general one would prefer the smaller FTOG trees than the
larger A/B trees, even if there were more total TOs. The ability to
prune FTOG graphs seems much more reliable than in an A/B where any
function in the system might rely on a given buoy you'd be paralysed
to make changes. Adding new is easy, reusing is trivial, but pruning?
Sounds like it would be very hard.

So, I'm on this fishing expedition for opinions on the subject. Plus
writing all this down helps me organize my own thoughts on the
matter.

As I see it, equivalence to SQL views doesn't really favor A/B over
FTOG. Interestingly, SQL views almost exactly match FTOG + A/B ie...
take each FTOG group, and break it down into strict A/B groups within
that function. That gives you "one view" per base table, per function,
which is pretty much exactly what you'd do in a SQL environment.

As an FM methodology it would, I think, be cumbersome without many
real advantages over FTOG by itself.

thanks,
Dave