Have a use case with the following data model
An object (parent) has an attribute object-data (color, size, etc)
When defining object-data should I have attributes
- belongs-to-object (the parent) which creates a circular reference (in my head)
- parent-id and store the parent’s unique-id (as a text field).
I’m leaning on option 2
Logic for maintaining a reference to the parent is so that I can create an audit trail of changes. If parent’s object-data is modified, I can create a new object-data with the new values and replace the existing one (which would leave the child within it’s own table with a reference back to the parent via it’s unique id).
Is there a preferred method to implement this pattern?
Definitely not option 2. Whether you add a link to the parent on the object-data or put a list of the object-data in the parent or both, you should certainly not use a text field to store the parent’s UID. There is practically zero advantage to storing the UID in a text field over linking the object and there is lots of admin involved with doing it that way, as well as many more additional lookups and limitations.
Thanks. I’ll use the object reference for now.
Just concerned that we have a parent-object, containing a child-object where that child-object references the parent-object
I’m getting the view that the child-object reference to parent is similar to a foreign key (rather than object contained)
TLDR: Unless it’s referenced (and therefore downloaded) it’s just the weight of a text field…
1 Like
Thanks - making more sense now.
So, it should be
- parent-object has a child-object as attribute
- child-object has a parent-object as attribute which is set to parent-object when being created (would already be downloaded at that point).
- I should always reference parent-object (not child-object’s parent-object) which will minimise download
I can then analyse child-object data later to see audit trail for this parent-object.
Thanks for the prompt replies here
