Hey - general question on naming conventions

[Singlequanta]

I've been using FM for a billion years now, ever since Filemaker 2.0. I've evolved my approach and and technique as FM has evolved as well. In recent years i've also gained a fairly good understanding of other DB environments (sql etc)

So here I sit performing a conversion project for a client from FM5 to FM8. I'm muckin around with 14 tables and over 1000 fields. (Yes there is definately room for more separation)

And the though strikes me as I'm looking at some of the relationships in this solution:

Does anyone out there have a preferred naming convention for relationships?

Im kinda adopting this strategy:

TABLENAME1|TABLENAME2~keyname as the actual name of the table and relationship

any ideas? any feedback? Anyone have a better approach?

Steve

[T-Square]

I try to name my relationships either functionally:

Clients On Site (for a TO based on the Clients table that is related to Sites by SiteID)

or descriptively outlining the relationship:

Global Clients to Sites on _g_Primary

I like to note relationships that are based on Globals in the name.

[CyborgSam]

I've been using a similar format, although it gives the most info, it is not intuitive and the names can get too long too fast...

TO|Field__to__OtherTO|OtherField

Note that TO is not necessarily the name of the underlying Table. For relationships based on a TO in the above format, that TO is enclosed in {}

{TO|Field__to__OtherTO|OtherField}|YAField__to__YATO|YAOtherField

[FMDuck]

Here's an example of what works for me...

COM__COMPANIES (always associate a layout with a parent TO)

|

-- com_People (after you use this, common sense implies this is people within the company)

|

-- com_People_byState (this is an example of an exception to the common sense rule)

PEO__PEOPLE (if you have a People layout, you need a People parent TO)

|

-- peo_Company (the same as the one above but duplicated for clearity - this way you can always be clear on your context for calculations)

This allows your relationships to sort properly and although you may occasionally have to go to your graph to see what's what, you can cut down on your Let statements and pick relationships faster.

One thing to remember is whenever you create a new table, use the FIRST TABLE OCCURANCE as the parent TO otherwise you will always need to change the context when creating a new calculation.

I have solutions with over 300 relationships and I rarely need to look them up on the graph when referencing one.

Additionally, since this forum is on The Seperation Model, FM will by default italicize TOs that are from an external table and also make them slightly lighter in shade.

Edited November 23, 2005 by Guest