Table/Relationship Naming Conventions?

[xochi]

Given the existence of table aliases (Table Occurrances) in FM7 and bidirectional realationships, it seems that naming your TOs clearly is of increased importance. Has anyone come up with a clear way to do this?

So far, the best thing I've come up with is this method:

"[TableX] to [TableY] by [MatchField(s)]"

e.g.

"Worker to Salary by WorkerID Date"

However, I'm not totally satisfied with this for several reasons. First, since one table is listed before the other, it tends to imply a one-directional relationship. I suppose since the TO is linked to a specific table, this TO should be listed first. Also, if you use long table names, the match fields are often not visible (cut off) in popups, which makes seeing which relationship you are using a bit hard.

Any suggestions?

[xochi]

Given the existence of table aliases (Table Occurrances) in FM7 and bidirectional realationships, it seems that naming your TOs clearly is of increased importance. Has anyone come up with a clear way to do this?

So far, the best thing I've come up with is this method:

"[TableX] to [TableY] by [MatchField(s)]"

e.g.

"Worker to Salary by WorkerID Date"

However, I'm not totally satisfied with this for several reasons. First, since one table is listed before the other, it tends to imply a one-directional relationship. I suppose since the TO is linked to a specific table, this TO should be listed first. Also, if you use long table names, the match fields are often not visible (cut off) in popups, which makes seeing which relationship you are using a bit hard.

Any suggestions?

[xochi]

Given the existence of table aliases (Table Occurrances) in FM7 and bidirectional realationships, it seems that naming your TOs clearly is of increased importance. Has anyone come up with a clear way to do this?

So far, the best thing I've come up with is this method:

"[TableX] to [TableY] by [MatchField(s)]"

e.g.

"Worker to Salary by WorkerID Date"

However, I'm not totally satisfied with this for several reasons. First, since one table is listed before the other, it tends to imply a one-directional relationship. I suppose since the TO is linked to a specific table, this TO should be listed first. Also, if you use long table names, the match fields are often not visible (cut off) in popups, which makes seeing which relationship you are using a bit hard.

Any suggestions?

[Ender]

I like to keep my TO names simple, specifying the path only on duplicate TOs.

If table X is the base table for the table occurance, then I'd name the TO "Table X by [Filter/Primary Path TO]", leaving out the keys from the name unless it's necessary to distinguish it.

So from your example, I might have a Salary TO related to a Worker TO by Worker ID, but since this is the primary relationship between these two tables, I'd simply name them "Salary" and "Worker." Then for the Salary TO that uses a filter by Date, I'd name it "Salary by Date."

I suppose the important thing is to try to use the same naming convertion throughout your solution so that you, and developers that follow, will be able to figure out what's going on.

[Ender]

I like to keep my TO names simple, specifying the path only on duplicate TOs.

If table X is the base table for the table occurance, then I'd name the TO "Table X by [Filter/Primary Path TO]", leaving out the keys from the name unless it's necessary to distinguish it.

So from your example, I might have a Salary TO related to a Worker TO by Worker ID, but since this is the primary relationship between these two tables, I'd simply name them "Salary" and "Worker." Then for the Salary TO that uses a filter by Date, I'd name it "Salary by Date."

I suppose the important thing is to try to use the same naming convertion throughout your solution so that you, and developers that follow, will be able to figure out what's going on.

[Ender]

I like to keep my TO names simple, specifying the path only on duplicate TOs.

If table X is the base table for the table occurance, then I'd name the TO "Table X by [Filter/Primary Path TO]", leaving out the keys from the name unless it's necessary to distinguish it.

So from your example, I might have a Salary TO related to a Worker TO by Worker ID, but since this is the primary relationship between these two tables, I'd simply name them "Salary" and "Worker." Then for the Salary TO that uses a filter by Date, I'd name it "Salary by Date."

I suppose the important thing is to try to use the same naming convertion throughout your solution so that you, and developers that follow, will be able to figure out what's going on.

[RalphL]

Take a look at this:

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

I am leaning in this direction. TOG's are based on layouts, I use the table names, i.e. Table A Table B. This giive me more TO's but the graphs are easy to read and the relationships group in the popups.

[RalphL]

Take a look at this:

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

I am leaning in this direction. TOG's are based on layouts, I use the table names, i.e. Table A Table B. This giive me more TO's but the graphs are easy to read and the relationships group in the popups.

[RalphL]

Take a look at this:

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

I am leaning in this direction. TOG's are based on layouts, I use the table names, i.e. Table A Table B. This giive me more TO's but the graphs are easy to read and the relationships group in the popups.

[xochi]

I like the ideas on that web page. However, I find that in the solution I'm writing, I have a bunch of similar-but-different relationships, where I need to have the key fields showing. This may be a weird situation, as I'm dealing with dirty / non-normalized data so I have to use a bunch of partial matches (i.e. Last name, LastName+FirstName, LastName+FirstInitial, Last+First+AgencyCode, etc.). I find that if I don't have the key fields in the relationship name, I go crazy

[xochi]

I like the ideas on that web page. However, I find that in the solution I'm writing, I have a bunch of similar-but-different relationships, where I need to have the key fields showing. This may be a weird situation, as I'm dealing with dirty / non-normalized data so I have to use a bunch of partial matches (i.e. Last name, LastName+FirstName, LastName+FirstInitial, Last+First+AgencyCode, etc.). I find that if I don't have the key fields in the relationship name, I go crazy

[xochi]

I like the ideas on that web page. However, I find that in the solution I'm writing, I have a bunch of similar-but-different relationships, where I need to have the key fields showing. This may be a weird situation, as I'm dealing with dirty / non-normalized data so I have to use a bunch of partial matches (i.e. Last name, LastName+FirstName, LastName+FirstInitial, Last+First+AgencyCode, etc.). I find that if I don't have the key fields in the relationship name, I go crazy