After you’ve identified the basic design of your database, you’ll have to add tables and table occurrences to the Relationship Graph. There are numerous ways to organize the Relationship Graph; however, I’ve found the Anchor Buoy method the most practical and logical.
In AB, each layout is based on an “anchor” and related tables are represented as a “buoy”.
A-B affords numerous advantages. One of the most important, is performance. FMs relationship graph is more than a modeling tool; each relationship is, in effect, a query. The more relationships that exist in a TOG (Table Occurrence Group), the more time it takes to evaluate. Add to this unstored calc fields that span relationships, and the performance impact grows. Keeping TOGs to the minimum needed for the UI in play, is imperative.
One of the visual aids in any A-B endeavor, is TO naming conventions. There are no set standard, and it is all person preference.
Here is my take:
Start each TOG TO, with a unique acronym; I use t10 for one group, and t11 for another, and so on. Makes selecting the right TO from the right TOG much easier during development.
I append each T+2 digit number with an a, b, c, d for parent, child, grand-child, great grandchild table. Sorts them in the right order to reference
After the group ID T10a, an underscore plus the table name, ALL CAPS
For the child, the parent goes lower case, and the child name is ALL CAPS
Between each relationship is a ~ID~ (or whatever the relationship is built on)
The base table of every TO is in the name in ALL CAPS; all other table names in the relationship are lower case
All names in the TOs are identical to the base table that is being referenced.
I've refined this over the last decade, and my current approach is what seems to work - at least for me. Each TO name has significance in the name itself.
And if a relationship sort exists, the TO name gets an _s suffix
No ambiguity or cross-reference interpretations required; the names are unambiguous but not so explicit that it is provides onerous detail. If connected on ID or a global match field, or contains a sort, that is just the clue to go check out if that TO is the one matching your needs.
One other footnote: IF you are developing FM on a Mac (is there any other way?) the $10 investment in Monodraw is money well spent. You can draw out the TOG as ASCII really quickly, and place it in a comment in the code that uses that TOG. GREAT visual aid
We use table names for anchors. We prepend the file name to anchors of foreign tables when multiple anchors have the same table name in multi-file solutions.
We append the table name of the buoy to the anchor name for buoy names. We append a qualifier when multiple buoys share the same table in a table occurrence group.
Keep in mind our nomenclature for files and tables support the nomenclature for the relationship graph. That said, we avoid codes as best we can to make table occurrence names as easily decodable as possible.
Example: Say we have tables Customer, Invoice, LineItem and Product. Anchors would be: Customer; Invoice; LineItem; Product. You would need the following buoys to answer "Who ordered product X?": ProductLineItem; ProductInvoice; ProductCustomer.
The hierarchical naming convention for TOG elements logically organizes the TOGs in alphabetic, sequential groups. When selecting a TO from a list, having them in TOG structure, is immensely valuable. One FM db I am currently working in has a couple thousand TOs; managing without this naming structure (which is reality at this client), is an extremely time consuming and error prone effort at best.
Alpha-numeric sorting in lists for table occurrences (TO) is useful.
I worked with a developer who left every TO with the original table name and the numerical suffix table_2, table_3, table_4. The TOs in the relationship graph were stacked in columns arranged alpha-numerically, so you had no sense at all about groups or connections.
I really don't get the benefits of that naming concept.
Why would I start the name of the TO with the name of a foreign table?
Line items do not become invoices in the first place.
My decision for my naming schema was based on the use cases. If I need to place fields on a layout I don't want to be shown 20 related TOs all starting with the anchors name. That does not offer any info because I already know I am using that context. Type ahead doesn't become easier too. Plus on Windows many FM interfaces like the export GUI don't have adjustable columns so I don't have to give away expensive place for information.
My naming starts with the table the TO is based on. Kontext (anchor name) comes in second. Third one is the condition/key the relationship is based on in the working context.
Finding one TO from a TOG among say, 2000+ TOs when there is no concept of a TOG in the name, or no indication of the depth and relationship structure within the name, is very, very error prone and time consuming. Having to open and search the relationship diagram for a given TO name to see if it is part of the TO group, drill down on each relationship to see how they are related, and determine the parent<>child<>grandchild relationship, WITHOUT a TO naming convention that provides this insight, is extremely counter-productive.
The rationale of an ALL CAPS base table in a child/grandchild TO, with the parent foreign table tree as a prefix, clearly defines the relational structure.
Of course, if each layout's field set is only based on the base context of the layout - a single TO - then TO naming conventions afford little benefit - at least until you add a related field to a layout, or a portal or 2.
hm, I didn't say I don't use a concept for TO-naming, only questioned the common usage of putting the anchors name first. I maintain solutions with more than 1500 TOs myself and without naming conventions I would be lost alright.
