• 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)

    Schedule » People

    good

    A Persons Schedule

    bad

    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.

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.

  • No labels

14 Comments

  1. Anonymous

    How does this work with Anchor-Buoy?

    1. Anonymous

      I second the request for info re compatibility with anchor-buoy. Is convention a different paradigm than A-B?

      Thanks,

      TomR303

  2. 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

  3. Anonymous

     Mac guy.  How do you enter Alt+0187 on Windows?  Hold down Alt while typing in 0187?  

    Doesn't work for me.  Help.

    1. 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!

      1. Anonymous

        Thanks.  I see that some of my questions are covered under Table Naming

        as long as I read all the comments too. 

  4. Anonymous

    Can you give more examples please?  Ones several tables deep.

    Is this C » B » A? 

    Or C » A?

    1. 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.

      Invoices » Invoices
Invoices » Lineitems
Invoices » Products

      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.

      InvoicesLineItems » Invoices
InvoicesLineItems » Lineitems
InvoicesLineItems » Products

      Does that help clarify?

  5. Anonymous

    More examples of FunctionalAreas please.

    1. 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.

      Faculty » People
Students » People
Estimates » Sales
Invoices » Orders
Invoices » Transactions
Inventory » Products
Inventory » Supplies
Customers » People
CustomersBigSpenders » People
CustomersFrequentBuyers » People
InvoicesUnpaid » Sales
ProposalsByPriority » Contracts
Preferences » Globals
PreferencesUser » Users
PreferencesPortal » Preferences
SidebarResourcesPortal » Resources
SidebarFiltered » People
Customers » Notes
Vendors » Notes
Orders » Notes
People » Attributes

      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.

      1. 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

        CustomersLayout » People

        Is less ambiguous in relation to

        Customers » People

        These would go in Best Practices of course. Feedback?

        1. 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.

          1. 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.

  6. Anonymous

    Is it really good idea tu use " " [space] between "@" and developer table name? It makes problems if somebody use sql queries.