relationships graph layout--best practice question

[douglasgifford]

I'm starting what will be a fairly complex FMP7 project (first time from scratch in 7) and am wondering what you clever folks think about layout choices in the relationships graph.

How to use colours.

Using an empty table for labelling.

And especially, whether it is wisest to set up small (i.e. just for one layout) clusters of relationships or whether to try to get everything connected to everything in one big cluster. The former seems neater and probably easier to read but may be trading off some possibly powerful connections.

Any thoughts based on experience?

[Fenton]

Colors: each base table has its own colors, consistent throughout the graph. So you know at a glance what base table you're looking at.

Empty "label" table: If you have a lot of Table Occurrence Groups (clusters, TOG), a good idea. Otherwise not.

I tend to still use the "cluster" approach. Especially when I'm sure of what the main connection between the tables are going to be.

I've seen others (Lynn Bradford, an expert by any measure) recommend a TOG for each main table, at the left, and the other Table Occurrences (TOs) branching off to the right. I can also see how this would work, as the relationships are now bi-directional.

Perhaps I should try this from the first. One often ends up with something like this in the end anyway; ie., multiple clusters, each with a different main base table in the center.

The trouble with multiple disconnected TOGs is that it can be a little frustrating sometimes when you are writing a script. and see that "you can't get there from here." That is, your current layout cannot access a Table Occurrence (TO) connected directly to a layout where you want to end up; that is, a Go To Related Record cannot reach the specific layout in one step.

In this case, all you need, after your Go To Related Record to get to the records you want, is an (extra) explict "Go to Layout" step, to flip to the destination layout, of the same base table you want. But this adds an extra "step over to the layout" to the script.

Hopefully someone else will chime in on this. Because it is a very important question.

[douglasgifford]

My colouring scheme for base tables has been a bit sporatic because I could never rememember quite which colour I had assigned which table (this is, in part, my own short-term memory issue). There is, though, a named list palette in the Colors palette (the third one from the left under "others..." when you choose a colour) that allows you to create named lists of named colours. Now I have a "table colours" list with colours named for the tables they represent. The "contact" table occurrences are given a colour called "contact" and so-on. You can even do searches for colour names (it would be one humungous database that would need that!)

[Ender]

I agree with Fenton, although I tend to keep things connected on the primary relationships.

I would add that using a consistent naming convention is important. I use the Table Name for the primary TO, and Table Name by Path for additional TOs.

[RalphL]

Take a look at http://www.sumware.net/robfm/conventionalnaming.php. Rob color codes by TOG's and makes the TOG's specific to views. I personally like to color code by Table. In the Separation Model example where I do 3 Files, I use the same color code for all 3 files. I feel that I am still learning and experimenting. This week I took my demo files of Separation Model Many To Many and redid the graphs from a single TOG to multiple (4) TOG's. In this small example, 3 tables + Global table, I am not sure that there is any advantage to using this many TOG's.

[Fenton]

He changed the address: http://www.sumware.net/robfm/ will work.

His graph "looks" good, but I don't agree with his "color by TOG" scheme. He has already labelled the entire TOG with a "dummy TO" bar; that seems sufficient for navigation. For me the whole idea of the colors is to identify the base table of each TO quickly from the color, within each TOG. Yes, I could just use the names. But the color is so much faster.

A combo of the methods would be to use the color of the main TO of each TOG, which would likely be a different base table, as the color of the "dummy TO" label bar.

I like his "name TO by TOG" idea. He's used a simple 2-letter abbreviation at the beginning of each TO name. This positively identifies the TOG AND sorts them together in the drop-down lists.

I often "number" the TOGs, with a suffix number: Events, Registrations, Events1, Reg1; so I can easily tell them apart. But they don't sort together in some of the drop-downs: Go To Related Record dialog. They do in the calculation dialog drop-down, because of "related" and "unrelated."

His method requires that each TOG has an easily recognizable central table or function, to abbreviate. If the graph is large, the number can help you find the relative position of the TOG; but that would be a pretty large graph :-|

He's doing it by function and views (layouts I image), which is good, as it goes; but, as Ralph says, it means quite a few TOGs. This is perhaps the main question we all have. When do you need a new TOG, and what should be its focus?

I also liked Lynn Bradford's idea, which is similar to his, which is to start a TOG for each main table, at the left of the graph, with its TOs streaming to the right. This allows you to have a "plain" TO for the base table's layout.

In reality I tend to have something like this; but by the time I add self-relationships TOs and "read from reference table" TOs, it tends to look more like a "solar system," but heavier on the right side. This brings up a point. Even though most relationships are bi-directional, I like to put my "read from" and self-relationship TOs to the left of (or above) the main TO, and my "set to" TOs on the right of (or below) it. It matches the way I think (left over from 6). Also, it's just too much sometimes to make them all to the right of the main TO, which can have so many.

I don't really see the need to prefix each field with its table abbreviation. I can't think of a time when I wouldn't already know what table a field is in, from the TO name, which is always present (if I can't tell, then my TO naming is insufficient).

I've also found that it's helpful to take a quick screenshot of the Relationship Graph, to save so much flipping back and forth (though I've recently assigned that to a mouse button :-). I like his idea of setting it as the desktop picture; though it would get old in hurry. On a Mac, you could do this with AppleScript:

tell application "Finder"

set desktop picture to choose file

end tell

But in reality, I think I'd just flip back and forth to the Preview app and leave the picture open. Same functionality; much less hassle.

[Ugo DI LUCA]

Hi,

Viewing Rob's article a month ago made me actually switch from my earlier settings.

I started with the Table color code myself, but when the solution got complex, I never felt confident either of using colors or Solar Systems. I can't think of how many times I changed my mind, and therfore Layouts, scripts, calcs, etc.

Since then, I started thinking Groups and Modules rather than Tables, and apparently my brain got finally plugged and the solution seems quite understandable, from the graph or from the dialog boxes within the calcs/scripts settings.

I find the Group reasoning quite more logical after all, and may be even closer to the solution you'd be developping which often have modules or separate activities (The Client Management, Product Management, Sales Management, Purchase Management, Mass-Mailing Utility, etc.).

I used the TOG_table_NameTable structure, leading to "PM_ord_Orders". It's not very convenient in the Graph but makes it really easy to select the correct Table when you got a list of 10-15 Tables possibly related.

This also allows to keep Generic Names, still being able to distinguish where this Table Occurrence appear, as "PM_ord_Orders" distinguished from "PM_li_Orders" where one looks to the Order Table and the Other to the Line Items.

When I have my 10 groups in place, it's now easier to see what's going on inside, and may be even to set the Privileges according to your accounts. And even if this may not finally be a good design, you can still join the TOG together so that you have a mini database environment.