If you use Anchor-Buoy method of managing the Relationship Graph (RG), Relationships are one directional.
If Relationships are one directional, then it is possible to embed the...
Allow creation of records...
Delete related records...
Sort records...
...checkbox configurations into the Table Occurrence name, thereby increasing code readability and maintainability (for example when viewing a Table Occurrence in a Script).
[1] Do you use the Anchor-Buoy method of managing the Relationship Graph?
[2] If you use Anchor-Buoy, do you embed the Allow creation, Delete related, and Sort configurations into the Table Occurrence name, and if so, what is your naming convention...?
Suffix of a single [_] char if: NO Allow creation, NO Delete related, and NO Sort records
Suffix of [_C] char if: YES (√) Allow creation, NO Delete related, and NO Sort records
Suffix of [_CD] char if: YES Allow Creation, YES Delete related, and NO Sort Records (example image below)
We use the anchor-buoy method and use meta-data in table occurrence names to derive meaning from relationships. We also use model-view-controler design pattern, which means we have a data file. Relationship-based record deletion is limited to the data file which also means the deletion meta-data is limited to this file.
We found value in knowing which relationship allow for deletion. Same goes for sorting. We found there is too little value in knowing which relationship allows for the creation of records so we don't bother.
Our separator is a triple underscore (___). We also use single and double underscores in relationship names. We use d for deletion and s for sort. We also use r for reverse chronological sort. We've yet to need other meta-data characters… but that can change.
What is the perceived value of naming a TO with a delete suffix code?
I'm wondering because the effect of the delete option affects all TOs based on the "other table" within the file. As soon as you define a relationship with the option Delete related records in this table when a record is deleted in the other table, lets say delete related records from "TO_B" when a record from "TO_A" is deleted. If "TO_A" is based a table "contacts" and there are several TOs based on that table, then the delete will be triggered when a record is deleted from table "contacts", regardless of which particular TO was active when the delete occurred.
Should you mark all of the TOs that will be affected "_d" or should you name the table that will be affected "_d" ?
However, the danger lies in deleting the parent record, not the child, so should the parent carry the "_d"?
I should say that I stopped using this option a long time ago in favour of scripted deletes. Now that we have transactions we have a much better, safer tool, imo.
I also only delete via script. Deleting via relationships is too dangerous for me! Things have happened to me in the past that I didn't want to happen.
On the other hand, I use the creation of records via relationships quite often. At least where I don't have to script something anyway, e.g. for a plausibility check.
As mentioned, we have rules regarding cascading deletions. Safety is the reason behind these rules.
The rules:
cascading deletions can only occur in the data file;
cascading deletions can only occur between an anchor and a second-level table occurrence;
an anchor's name is always the name of its base table (in the data file).
The above rules came into existence because I've had the pleasure of resolving unexpected cascading deletion issues. They ensure that the cascade deletion between a base table and any related base table can only be defined once in a solution. The deletion meta-data make it easy to understand all the deletions that can occur and when… and all this information is contained in a single location for a solution.
We considered the scripted approach. We chose the above approach because: the database engine handles everything for us; such deletions are transaction and crash safe.
This behaviour has always seemed so out of place and counter-intuitive. Cascade delete should only be permitted using the TO where this option is specified, from the originating context, NOT any context. It's the main reason we avoid using cascade deletes, you simply can't trust it.
We find cascading deletions to be desirable when viewed from the perspective of data contraints and consistency. If my entity-relationship diagram (ERD) says that entity B data can only exist if entity A data exists, then regardless of context, entity B data must be deleted when entity A data is deleted.
That said, some ERD relationships cannot be modelled in FileMaker's relationship graph. I readily admit that scripted approaches to deletions are needed from time to time.
That's what the visualisation in the RG lead us to believe. The Create records checkbox is only valid for that specific relationship. Yet the Delete option is true for all TOs.
What's more , the RG is consistently misleading us because they should have some way of showing that the related records in the underlying table will always be deleted regardless of which TO the parent record is deleted from.
I appreciate that the checkbox enables a strict policy for the delete. What annoys me is the lack of signalling within the RG and the Database Manager generally.
Given the fact the graph has practically not changed since V7, it's likely this will not change any time soon.
It also speaks to Claris' ongoing lack of understanding of real world solution design and structure. Cascade delete makes sense in a starter solution with 3 table solution where the RG resembles the world's simplest ER diagram, but that's about it.
