- Table occurrences: are always suffixed (not prefixed) with their "base table" name and separated using the » character ( Right-pointing Double Angle Quotation Mark – \x00BB ) using a space on either side of the ». The prefix is TitleCamelCase and indicates the functional area or use within the solution.
Option-Shift-Pipe (Mac) or Alt+0187 (Win)This method of table occurrence naming is the inverse of the more popular method of using the "base table" name first. This requires a very strong focus to pre-define functional areas in your solution before hand! Sorting of table occurrence names is based on functional domain instead of base table name. Note, however, it's very easy to rename table occurrences if the functional realm changes for a particular group of table occurrences.Schedule » People
good
A Persons Schedule
bad
Note: The goal of using FunctionalArea » Tablename is to force a degree of self documentation for the distinct areas of your solution. The FunctionalArea itself can be extended as long as it stays TitleCamelCase. For example:
NavigationAll » Menuitems NavigationByAccess » Menuitems NavigationPortal » Menuitems
Where Menuitems is a self explanatory table name and the keyword All may indicate a Cartesian product relationship, the keyword ByAccess indicates the involvement of a possible User table and the keyword Portal clearly indicates its use as a portal table occurrence.
Web compatible variation
The use of the Right-pointing Double Angle Quotation Mark is simply for readability within the realm of a FileMaker solution intended for use within a FileMaker client/server setup. When implementing a web publishing strategy within your solution it is suggested you use the best practice of the various Solution development models. If this is either not possible or preferred, the variation of table occurrence naming would simply replace » with a double underscore __ and remove spaces. Therefore the resulting examples above would look like so:
NavigationAll__Menuitems NavigationByAccess__Menuitems NavigationPortal__Menuitems
Using a double underscore differentiates a TableOccurrence__Basetable from id_ForeignKey or key_CONSTANT when scanning through code.
@todo: should we come up with a list of suggested terms
- Table occurrences: which are dedicated for internal development and have no relationships are prefixed with the @ symbol and one space
This sorts developer table occurrences at the top of the list for selecting tables@ People
good
Developer People Table
bad
Duplicating Table Occurrences
Some of the comments below provide information about how to access the « and » characters on Windows using Alt key combinations. Keep in mind that simply holding down the Option key (Mac) or Control key (Win) allows you to drag-duplicate a table occurrence. You can also use the duplicate button with the double plus signs. This an easy way to not have to "remember" what the key combination is for the » character.
14 Comments
Anonymous
How does this work with Anchor-Buoy?
Anonymous
I second the request for info re compatibility with anchor-buoy. Is convention a different paradigm than A-B?
Thanks,
TomR303
Anonymous
There shouldn't be spaces in TO because otherwise you loose the feature of typing first letters to jump to th e TO in the graph, especially with Clip manager excellent occurence selector
Anonymous
Mac guy. How do you enter Alt+0187 on Windows? Hold down Alt while typing in 0187?
Doesn't work for me. Help.
Perren Smith
Make sure you're using the number pad to enter the numbers, the number keys on top of the keyboard won't work. That and all sorts of other fun details on Windows Alt Codes can be found here: http://tlt.its.psu.edu/suggestions/international/accents/codealt.html
Good luck!
Anonymous
Thanks. I see that some of my questions are covered under Table Naming
as long as I read all the comments too.
Anonymous
Can you give more examples please? Ones several tables deep.
Is this C » B » A?
Or C » A?
Matt Petrowsky
There are only ever two table occurrences connected together. If I guestimate about your thought process with this questions, you're mentally connecting keys through tables - typically a join scenario.
The premise of this naming convention is such that the FunctionalArea is your opportunity to control how the schema "reads".
So in your question of C » B » A, we can use a common example of Invoice » Lineitems » Products. This would probably follow this line of implementation.
You can envision this within the graph as
Invoices » Invoices = Invoices » Lineitems = Invoices » Products
Where the keys used would look like this.
Invoices::id = Lineitems::id_Invoices | Lineitems::id_Products = Products::id
And remember, you will extend the FunctionalArea or solution realm in order to provide more more clarity.
So, if Invoices as your prefix for the TO is too ambiguious, then you would use InvoicesLineItems to clarify.
Does that help clarify?
Anonymous
More examples of FunctionalAreas please.
Matt Petrowsky
The use of the FunctionalArea really depends on how you're building your solution. All of these could be used in various different solutions.
Some of the above came from some of my own solutions, yet others are just ideas of what some TOs might be named.
The key is that simplicity and clarity is what will make your solution easy to "read" when looking at the Relationship Graph.
I tend to reserve the most obvious and general terms for the TOs where layout interaction will occur. So Invoices is reserved for the interaction, where InvoicesUnpaid is an extension of the Invoices realm and is more specific in terms of FunctionalArea.
The key to this whole convention is that nothing is set in stone. If you determine that a group of table occurences needs to be renamed then all you have to do is double click and rename the prefix on those TOs that apply.
The BIG advantage to doing this is that selecting from FileMaker's popup menu is that your occurrences are grouped by functional relevance. There may be those times when you need data from X tables away and the prefix name is not the same, but those will be much more rare than working within a given FunctionalArea realm.
Matt Petrowsky
One other thing, note the use of certain keywords used on TOs. Terms such as Filtered and Portal give clear indication of where that particular TO fits into the solution.
Should we start to define some of these Table Occurrence Modifier Terms?
For example:
Layout is certainly obvious
Portal implies the TO is used as a portal
Filtered implies Portal with filtering turned on
Is less ambiguous in relation to
These would go in Best Practices of course. Feedback?
Perren Smith
I agree some hinting via naming is good, but wonder if singular modifier terms will be adequate. What about instances where I have defined a child TO with the intent of using it for multiple portals, filters and/or layouts? It's a nitpick, but all I could come up with. Personally I'm sick of using graph text objects as the only way to document which TOGs are for what - it's not easily exposed to others who can do layout and scripting work (yet no define database) in a multi-dev environment.
Other modifiers I see as useful are:
Field for TOs specifically used for field calculations in define database. In separation model this wouldn't be as big a deal, but solutions that aren't fully separated yet benefit from keeping UI TO clutter out of the data graph.
Script for TOs only intended to be used in scripting, never for UI / layout work.
Matt Petrowsky
I like the idea of the Script modifier. However, I've ended up using TOs for UI based %displayCalcs. Maybe Utility?
Anyway, if you're following this thread of comments then please DON'T COMMENT HERE about Table Occurrence Modifier Terms. Instead, follow the link and add your comments there.
Anonymous
Is it really good idea tu use " " [space] between "@" and developer table name? It makes problems if somebody use sql queries.