Just begining to play with FM 7, converting a solution with 45 tables, and hundreds of fields and relationships.

It seems that the relationship graph could get very big, very cluttered, very fast. Has anyone thought about any conventions for setting up the table and for naming the relationships so that it is easy to work with as it grows?

For example, I'm trying to think of a way to name table instances so that I can quickly tell what's being referred to. Something like

BaseTable~RelationshipDescriptor

So I'd know that "People~Workplace::Phone" is the phone number of the workplace of a given person.

I'd love to hear what others are thinking before I muck this up too badly...

Thanks,

Dan

Hi. This is actually my first post ever. I definitely hear what you're saying regarding the graph. My first development project is a large one and my graph has become very confusing, not just from a naming standpoint, but also from a space standpoint. I'm not sure how to simplify things so that down the road my graph is more clear. Anyone have any suggestions.

I don't think there is an easy answer. Nameing conventions are a mather of personal preference. I use the table name plus some descriptive info to name the TO's. I use a full size TO showing all fields plus one line for each table. All others show only the key fields. I move them to reduce the number of relationship lines crossing. I also color code the TO's by table.