This is a work-in-progress inspired by a recent conversation.
In the "separation model" in FileMaker, where data tables live in separate files from an "interface file" containing visual layouts that display the data to the user, used to be widely recommended as a development convention. However, many developers have found that it has significant drawbacks. This is a scratchpad list of those drawbacks as I encounter them.
1. Duplicate relationship graphs
In practice, relationships depend on context, and this is provided by table occurrences that layouts are built on. You may need a portal on a layout... that means the relationship must be in the interface file. But you may have a calculated field in the parent record that counts, summarizes, or otherwise performs an aggregate operation on the related records. That means the relationship must be in the data file. Neither of these is unusual at all. So you often wind up having to maintain parallel relationship graphs, manually keeping them updated, which is error-prone.
2. "Go To Related Record" problems
It's common in FileMaker to navigate by means of a Go To Related Record script step, which allows you to specify a destination layout to show the related records on. The problem is, if you do this to a table in an external file, you can only go to a layout in the file the table is originally defined in. In large systems built on the separation model, you often see more than one interface file... you might have Clients Data File with a Clients Interface File, then Invoices Data File with an Invoices Interface File. The problem then becomes, if you're in Invoice Interface File, and you want to use a GTRR to take the user to a related Client data entry screen, you can't, because none of the Client tables live in the Clients Interface File. So you may need to make 100% sure you only have one interface file for the whole system, which in big systems can be a pain.
3. Hunting down tables in "Manage Database..."
One of the nice things about having data and interfaces in the same file is, if you're on a layout in layout mode, you can hit cmd-shift-D (ctrl-shift-D on Windows) and the "Manage Database..." dialog box will open directly to the table the layout is built on. if it's built on a table residing in a separate data file, you have to go to the data file, go into "Manage Database...", and manually hunt down the table you want... which may have a different name than the table occurrence the layout was based on, since TOs don't have to have the same name as their basetables (and all too often don't.)
