This is a quick follow up to last week’s article on reciprocal (bi-directional) linking, and will assume the reader is familiar with that material. Paul Jansen of APJ Computing Solutions sent in a revision of one of my files demonstrating that, among other things, the graph could be a good deal leaner (as per my stated goal of making the approach as simple and lightweight as possible), and I am sharing that file today with his permission, along with my own attempt at further simplification.
Challenge: in a multiuser document management system, facilitate the linking (and unlinking) of any document with any other. Make it clear which documents are linked to the current document, and make sure the approach is multiuser friendly — in other words, allow document records to be linked and unlinked even if one or both of those document records are currently being edited by another user.
Today we have two demo files, one using standard serial numbers and one using UUIDs. Except for serials vs. UUIDs, the two files are functionally identical, and in the interest of clarity, I’m going to focus primarily on the serial number version.
[I want to start out by expressing major thanks to Jason DeLooze, who graciously read an early draft of this article, and with some outside-the-box brainstorming (a specialty of his), transformed my sluggish approach into a blazing speed demon.]
Many of the relationships we define in FileMaker are predictable and mundane. A field in table A is linked to a field in table B via an equijoin (=) operator. We do it every day and we’ve done it countless times. Of course we often define more complex relationships as well: ones with multiple predicates and/or more esoteric operators than the venerable equijoin.
Even in this (FM 11) era of filtered portals, we solve many design and business logic problems relationally. However, once in a while a challenge crops up that seems like it should be solvable using the FileMaker relational model, but that frustrates our initial attempts to do so. For example, let’s look at three tables from a sales database:
On our Products list, we’d like to be able to set a date range in the header, and then see cumulative sales for each product during that period. Continue reading “Filtered Relations, part 1”