Relationship Graph & ValueLists by Groups like ScriptMaker

[joaocarlo]

Allow organize the graph of relations by groups or something.

Working with many tables or valueLists in complex information systems become very complicated and slow the programming… 4D already does this for a very long time… I will ask the most? :P

[Søren Dyhr]

Allow organize the graph of relations by groups or something.

Havn't you done that already, study the Anchor Bouy approach to the graph - could it be that you havn't read this:

http://www.digfm.org/ref/FM7_key_concepts.pdf

Where it's said very early "The RG isn't an ERD" ...page 6 to be precise!

I do personally hardly ever have more than some 10-15 TO's in my TOG's!

Achor Bouy is explained here:

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

--sd

[comment]

"The RG isn't an ERD"

No, but it is still a GRAPH, i.e. a visualization tool - alas, not a very good one.

study the Anchor Bouy approach to the graph

I've been wondering about this for a long time: what exactly is the problem that is supposed to be solved by anchor/buoy?

[Søren Dyhr]

Cluttering, isn't it?

--sd

[comment]

That's what I think, too. But is removing clutter by CHANGING the actual relationships a good solution?

Anchor/buoy does NOT provide the same functionality as the same ERD implemented by a cluttered RG. By taking the anchor/buoy approach, you rob yourself of the many opportunities offered by relationships being bi-directional. Basically, it's a cop-out: I cannot work with a cluttered graph, so I go back to listing the relationships just like I did in version 6.

(That's without mentioning the redundant duplication of relationships and layouts, along with suspected performance issues of anchor/buoy.)

IMHO, the clutter problem should be solved at the source. This could be done by three rather simple improvements:

1. Lines need to be orthogonal, not straight (this alone would solve 80-90% of the problem, I think);

2. It should be possible to place the SAME table occurrence on the graph more than once (Filemaker knows how to detect and prevent circular references directly, so the current limitation is unnecessary);

3. The graph needs pages and/or layers.

[LaRetta]

Wow! I agree with every word, Michael!! I've also (in the closet) adhered to simpler ERD graphs. When viewing them (if placed with a great deal of thought), they look no more cluttered than the Anchor/buoy (if not less). They are certainly faster in performance.

It is nice to come out of the closet about it ...

[grubber]

I've been wondering about this for a long time: what exactly is the problem that is supposed to be solved by anchor/buoy?

The problem it solves for me is simplicity and consistency. I was never really comfortable with the graph until I started using Johnathan Stark's 'Squid' conventions. article here and his faq here

I've built a 40+ table solution with it. It's got a lot of relationship sure but I've not had any noticeable performance issues? Its also a breeze to work with compared to a mixed bag graph I recently had to revisit.

Cheers

Olly

[color:gray]As Moderator, I repaired the quotes because it appeared that Comment said the entire post here instead of Olly. (LaRetta)

Edited July 18, 2008 by Guest

[LaRetta]

I'm not going to get into a debate on anchor/buoy vs. other methods. You might want to check out Ray Cologon's perspective in FileMaker Pro Bible as well. There are many approaches. But I was told by a top FM engineer that a simplistic old-fashioned method (after he viewed my graph from few years back) was extremely fast compared to 'other approaches'. Never having used a/b, I couldn't say.

It's like this ... if it works for you and you understand it then fine. But it feels like, every time someone mentions something different than a/b, that those who prefer Macs vs. Windows; or those who prefer Chevys vs. Fords stuff. I won't go there. I said what I preferred and there are good reasons which Michael pointed out. Pigeon-holes are for pigeons. :wink2:

[Søren Dyhr]

By taking the anchor/buoy approach, you rob yourself of the many opportunities offered by relationships being bi-directional. B

Good point indeed, but the feature wish that started this thread ... seemed to ignore the TOG'ing ... I'm not saying Anchor Bouy is without some serious restraints, but when you start to interchange you solution with another developer must some sort of mutually agreed protocol be observed, to prevent each developer in the team uses all his time to get the idea of another developers contribution.

Modularization is a must in teams to prevent looking in wrong places to debug.

--sd

[comment]

My point is that the weaknesses of the anchor/buoy model are partly not explored enough, and partly ignored. I have no quarrel with anyone who wishes to use it despite its weaknesses, but I wouldn't recommend it to others without pointing these out.

[Søren Dyhr]

This is almost like immediately refuse to use a lingua franca, to another because you can point out grammatical deficiencies in what's common ground.

Here is a way to cooperate on the development, and as it is with all artforms - Mastering it is actually to know when to break the rules:

LEST FOOLS SHOULD FAIL

True wisdom knows

it must comprise

some nonsense

as a compromise,

lest fools shouls fail

to find it wise.

--sd

[comment]

This is almost like immediately refuse to use a lingua franca

I don't think that's a valid analogy. The two methods are not equivalent. IMHO, anchor/buoy is not a common ground, but a throwback to the comfortable old (and less capable) methods.

[Søren Dyhr]

but a throwback to the comfortable old (and less capable) methods.

True! - Isn't it the same as speaking english where the use of systematic grammar is a little random, and you instead rely on remembering a vast number of standard terms, unfortunately tightly connected to the present geographical discourse.

--sd

[comment]

If you insist on an analogy, I would suggest this one: we have a camera, but it's difficult to operate and we haven't learned how. So instead of sending you a picture, we'll send you a written description of what we saw.

Note also that's it quite easy to take a "spider" graph and turn it into anchor/buoy, but very difficult to do the opposite.

[grubber]

I think everyone is right

I recently read a thread on a Ruby vs Python board which is quiet apt "Ruby programmers have more fun. I love Ruby, but I write any code that I intend to maintain for the next decade in Python".

i.e. Laretta has more fun where as I'm old fashioned but dependable.

Olly

[comment]

I think everyone is right

I don't - and I resent your implying that a solution is less dependable or maintainable just because it doesn't implement the techniques and ways of thinking of version 6.

[grubber]

I don't - and I resent your implying that a solution is less dependable or maintainable just because it doesn't implement the techniques and ways of thinking of version 6.

Wow. This thread is a tough gig.

OK how about this. You're right but I'll continue to be wrong.

Olly

[comment]

I didn't ask anyone to agree with me. On the contrary, I would welcome reasoned opposing views. I don't see that you have expressed one - in fact, you confirmed my principal claim right in your first post. This is not about being right or wrong, it's about making informed decisions.

This thread is a tough gig.

That's right, so hang on to that day job. :smile2:

[dmontano]

I will chime in to cast my novice thoughts on this...

I never took hold of A/B. I am not saying it's bad. It's just not for me. In my difficulties of trying to learn how to tie relations together - I gravitated towards a spider-like or constellation or clustering type looking graph. I do not know how to classify it.

The A/B method seems like a method developed to ease the hassle of naming TOs, locating Tos, knowing one's context, etc. That fact alone tells me that the RG in the A/B method is being structured to support the developers convenience first, the solution second.

That's not bad either - I guess. But isn't that going against what the solution's "best" interest are? I would think that the solution's needs dictate the graph - whether it looks like a spider, a constellation, a squid, or a monkey. Isn't the graph primarily a visual tool to help the developer execute the relationships that are needed to support the reason for the solution?

It seems to me that A/B to some degree was developed to ease the randomness and difficulties of finding one's way around. As I said - I am very novice so what do I know. I do think that its clever and well adopted - evidence that it is a option for those that like it.

I can tell you that I do prefer to let my need to connect what I think is the most efficient manner for the solution dictate what I connect and how I connect it - even though I still do not know how to connect what I want to connect in my head.