FM7 Relationship Naming

[Barbecue]

One of my priorities in naming tables, fields, and relationships is to keep the names very short, as this lets me work faster and see at a glance what things do. In the past, I have developed my own method for naming relationships on the tables involved, with the order of the table names determining the direction of the relationship. Now with automatic bidirectional relationships, things are more complicated. How are folks handling this?

[RalphL]

You may find this article interesting, it goes beyond relationships.

http://www.sumware.net/robfm/conventionalnaming.php

[owltech]

I name the relationship as follows:

"table 1 key : table 2 key"

for example, a relationship between the sales ID in sales table and the order table could be

sales sales ID : order sales ID

In case you have compound keys, then improvise a bit with the name. Or maybe (hopefully) the the relationship is unique, so just stick with the first key. I choose the colon separated by spaces in the name. It's clear in the various choice lists, and doesn't bother FM at all.

[Fenton]

Yes, it's kind of confusing. Personally I tend to use my own "compromise" naming scheme, which does not follow strict rules, but is tailored to what I need to see. It does have however have rules of a sort and is consistent. I agree with Barbeque, shorter is better. I don't put the originating table's name in the TO name, unless it's one of those "hanging off the end" TOs only used for reading data.

In 7 many paths may be going through multiple TOs. A TO itself can have multiple paths to it, from adjacent TOs. You cannot therefore name the TO to include the paths. Because you don't know which you're coming from. For any 1 TO, there could be multiple paths to it.

I often do put the field, and even 2 fields if they are different, and it's possible to get confused. For example, I don't put both if one is a global and the other is its regular field; if I just put the global I usually know what the other one is. I often abbreviate the names, if they are long, and if I can do so and still recognize them easily.

But, once again, this only makes sense in some TOs, where the hierarchy is clear, and you're only going one direction. I imagine this is one reason why some people advocate multiple TOGs, with the "main" TOs lined up on the left, tied to layouts, with subsidiary TOs going down the hierarchy to the right. In that case you'd seldom use a bi-directional relationship. You would tend to go in one direction in one TOG, but maybe using a different TOG to go back. I haven't done many large files with lots of TOGs; I tend to do more of a "cluster" approach; maybe someone who uses that structure may comment. But that would seem to be one benefit, less ambiguity; but at a cost of more TOs.

It is important to be logical and consistent however, or no naming scheme will really make sense.