This thread is very timely for me, and coincidentally I just reread Ray Cologon’s 2009 white paper on Graph Modelling. It’s striking just how relevant this paper still is today. Like many, I started using Anchor-Buoy and appreciated how it helped clarify things in terms of naming, but after understanding Ray’s criticisms of the AB model (mainly the extra work FileMaker has do to resolve all of the superfluous TOs when opening a file – which can be especially problematic when relying on PSOS calls) I began using more of a functional island/selector-connector approach which can look anchor-buoy like at the “island” level, but in fact does not use the prescribed AB naming conventions, and does not adhere to the AB rule that every table has its own TOG where it is the base table.
Additionally, I now use a table naming convention that focuses on the function of each table and TO (and also fields, custom functions, value lists and calculation and script variables, as well).
A typical, modestly complex solution for me will be separated into 2 distinct files: one for the Interface and one for what I call “Schema Tables”. Within each file, I then prefix all my table names with a code that describes their function. When sorted by table name, this allows me to easily segment my tables and see very clearly “what is what”. More significantly, it makes managing security and the user privilege sets vastly easier, as it’s quite obvious what the function of each table is, and who should have access to it.
Interface Files use the following prefixes for its table names:
_INTERFACE: Contains the global fields needed to control the interface and record access. (note that this is the only table that uses a leading underscore, which keeps the table on top of all the others when sorted by table name).
ADMIN: Administrator Tables: limited access (for administrators only) which control value lists and user accounts & privileges.
DEV: Developer Tables: limited access (for developers only) to help support the interface (e.g. look-up data for things like addresses).
LOG: Log Tables: limited access (for developers only) tables tracking sessions, scripts and errors.
For the Schema Tables file, the tables use these prefixes:
ENT: Entity (or "Core Data") Tables: the data that the database is meant to track and will belong to the client (as opposed to the interface file, which is my property that I will license to my clients but ultimately belongs to me.)
JOIN: Another type of Data table that links two or more ENT tables/table occurrences.
SYS: "System" tables are data tables that are the rough equivalent of FileMaker's add-on tables. For things like notes, attributes, etc., that can be linked to other "Entity" tables and helps me reduce field-level duplication (for example, having a "notes" field in each individual table).
Here is a good example of a table listing for a typical Schema Tables file:
Making clear whether a data table is a core “entity” versus a “join” versus a “system table” versus a “DEV” table or “Admin” table makes it much, much easier for me to manage my RG, and I use colors to reinforce these naming conventions. Thus, “entity” tables are all one color, where “join” tables are yet another color, and so on for each of the above prefixes I’ve listed.
On the RG, I always keep the exact base table name to the left immediately after the prefix, and anything that follows this is a description for what that table is used for. For example, for master/detail layouts in a contact database, I’ll have things like “ENT_Organizations_Portal” versus “ENT_Organizations_Selected”. I only ever use underscores to separate the terms (never periods as they can seriously complicate using the Execute DataAPI script step). And like FlyByNight, I prefer Pascal Casing over Lower Camel Casing.
Here's an example of how all of this would look on the RG within the interface file:
Note that the above is just one "island" within a bigger group of islands. You can see this below:
Note the legend at the bottom.
I also use prefixing for field names (a separate topic which I am happy to write about), custom functions (I always want to know whether a function is native to FM or something that’s been developed separately, and this eliminates the risk of FM one day creating a native function with the exact same name as one of my custom functions), value lists (whether a list is returning the contents of a Key Field versus “regular” data), and finally calculation and local/global script variables. Prefixing each with a short description of its function within the database helps me enormously.
I hope this is helpful, and thanks to everyone for contributing to this thread. I always learn something new here.
Peter Gerlings