Basically, I have about thirty tables with actual information, and some additional "working" tables for scripts and such.

What am wondering is my relationships screen too complicated? Am I missing something about filemaker uses relationships.

I have attempted to organize according the particular "function" and name the table occurrences accordingly. Needless to say I am finding it difficult to organize and name.

I have attached a screen shot of part of the relationship screen. There are nine sections each a green title bar: Unit Information, Lock & Keys, Tenants, Lease (for one script), Accounting, Reports, Management Screen, Value Lists, Separate (each table has an unrelated occurrence)

This is probably the wrong time to ask, but this just seems like a bit more than I expected.

Thanks,

Bill

Read some techniques here.

http://www.fmforums.com/forum/showtopic.php?tid/194294

Thanks, I will look these over.

I personally don't use a "function" based naming system. I use the path of the TOs (Table Occurrences) prefixed by a TOG (Table Occurrence Group), both abbreviated consistently. It makes it is easier to find the one you want in the hierarchy. Of course, sometimes I don't remember exactly what it's for -]. So I go and look; I know where to find it; eventually I get to know them well.

There is no perfect system which is both structural and functional; by the time it was it would be too long. Structural is a little difficult to remember what exactly each TO is for (though it can be for several things), and functional is not alphabetical at all.

But perhaps you could modify yours a bit to be a little more structural. I would do this by deciding on a TOG prefix ("UN" for Units, "LK" for Locks & Keys, etc.). Then I would preface each TO with it, all caps for the main anchor TO, lowercase for others (that's my system anyhoo). I'd do much the same for children and grandchildren, add a consistent little prefix. So you have a better idea where a given TO is in the hierarchy.

The main place this would pay off would be in Go To Related Record steps, where every TO is available (connected or not), making a very long and confusing list if you have only functional names.

Another thing you could do would be to collapse the TOs on the graph more, especially the child/grandchild tables. When you are first working on a file it is useful to show the fields in the relationships directly. But once you've got it mostly done, I think having all those TOs open just makes it more confusing to look at. Collapsing them doesn't really make it simpler, it just looks simpler. This can be done via command keys, Control-T (Cmd-T).

A 30 table solution can easily have 300 relationships, which is tricky to manage on one graph

in the "old" days, each table, and it's relationships, were in separate files, so easier to see

in define database, "fields" are displayed by table, but "relationships" are not (a feature request?)

at first glance, your graph looks better than most

greg

which is tricky to manage on one graph

Isn't just a fling when you for the first time approach the fm7+ approach, and accidentally confuses a ERD with the RG?? Have such urges ever happen since then??

But yes there could be reached a mile-pole where we although utilizing even the best practises, create problems for our selves - read how wise Corn puts it:

http://www.nabble.com/Re%3A-Under-utilization-of-the-context-drop-down-p14177505.html

--sd

As it turns the "Anchor Buoy / Hierarchical Table Occurrence Grouping (HTOG) Method" appears to be best suited for this application. I did, however, modify the color scheme to be functional. This has helped identify tables within a particular section more easily.

Overall, I would have to say that I like this a lot better than my previous attempt.

Now, the problem is to stay consistent.

Thanks,

Bill