Tagging, Flagging & Marking
Aside from the word "tagging" taking on new meaning in this Web 2.0 world, the method of simply marking a record for later retrieval is what this video is all about.
The simplest method of marking a record, starts with a simple FileMaker check box. This method, however, becomes quite unusable when you throw more users into the mix. Each user of the database will inevitably want to flag a different set of records - and beyond that, save multiple groups of flagged records.
The solution to this is easily handled with a relationship from an unstored calculated field, using Get (AccountName), to the user's dedicated record within a Users table. The method of storing a set of records as flagged, is then just a matter of a return delimited list of keys within a text field.
Using some creative interface metaphors, you can quickly add a very useful feature to any FileMaker database!
Comments
Comparison with join table
Would you use this instead of a join table for these kinds of many to many relationships?
For example, allocating students to a class in a specific timetable slot.
Obviously this breaks the 'proper' relational model, I'm just interested in your view on when one technique is better than the other.
The issue comes down to trust
Do you trust the code you are using? Sounds silly, but it's the question I ask myself.
From a data storage perspective, storing a key value in a single field (multi-key) with other values, versus a field within its own record in a different table (join relationship), there's no difference. Bytes are bytes on disk. You then move on to performance and data access.
The decision of using a table (and relationship) versus using a single field comes down to how frequent and in what fashion do you want to access that data. If you're simply using it to pull of the found set of related records then my question becomes, "Why go through the extra effort if you trust your own code?".
I've personally gone through the same struggle that many of us go through at one time or another. The "Is this the right way to do it struggle?". Fortunately, as you get more and more familiar with FileMaker, you learn it's perfectly "Ok" to do things in the might-not-be-accepted-way - the data doesn't care. [wink]
-- Matt Petrowsky - ISO FileMaker Magazine Editor
One further thing to note
I should also mention that you need to consider the implementation - from a user perspective. If, for example, you are wanting each user to have their own collection of found sets, then you know the likely hood of record locks on the simultaneous addition or removal of values is very unlikely (if impossible) because only the user who owns that record would be reading and writing to their fields on that record.
If, however, you want to allow users to access, and modify, other users' collections then it is [remotely] possible you would get a record locked conflict.
In that case, you might have to add a bunch of extra effort, via a join relationship method wherein you use unique identifiers such as the user id key values to make each collection a saved set where the potential for record locks does not exist - but, that is another topic for another day. [grin]
Matt
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Looks great ..... but
Hi
Looks great and something I could definitely use, however as there's no technique file with the movie, I'm lost as to how to implement it in my own system. Usually, I can pull apart the file and see how it works. Do you have a barebones sample file that demonstrates the functionality?
Files, free access and subscription
I would like to have a hands-on experience "always" with the technique file.
And it can be quite acceptable if it could be available only for subscribers.
I think as a creative way to look for the excellence..
Sometimes a technique without its own file is only 20% of the technique.
Please consider seriously such way.