Subtitle data essence in relation to relationships for objects with similar attributes
While planning the master data schema for my iOS app, I found that I have multiple entities that need the same set of attributes (e.g., descriptive text, rating, user notes, etc.) and relationships (e.g. for applying tags, adding parameters, establishing parent / child relationships, linking images, etc.). For one entity "Entity A" common attributes / relationships are all it needs, while the rest have several additional unique attributes and / or relationships. Reading the master data documentation and posts here, I decided to create "Entity A" as a parent to others.
One additional object has all the same attributes and a subset of the same relationships, and this is the object for images (note that the images themselves are stored in files, this object is for metadata and has a key to the image file). However, "Entity A" and children need many relationships with the subject of the image, while the subject of the image does not need a relationship with itself. The image object also doesn't need a parent / child relationship "Entity A". I see four options, but I'm having trouble figuring out where to go.
My question is whether any of these options have a significant pro or con that I am missing, or if a particular option is generally viewed as the "right" way of doing things. I've read that in Core Data, all child objects will share the same table with the parent, which can lead to performance problems for a large number of objects, but I expect my application to only require a few thousand rows in such a table at most.
Option 1 . Set up the image object as a child of "Entity A" and just ignore the relationships it doesn't need. This is the easiest to set up and take full advantage of inheritance, but I don't know if ignoring relationships is a good design choice. "Entity A" has existing data, which I think will migrate most easily this way, but I can also recreate the data without too much trouble, so it won't matter much. There is no current image object, so transferring this is not a concern.
Option 2 . Create an abstract parent for which both Object A and the Image object are children. The parent will be "Entity A" minus the relationship to images, and "Entity A" will now just be related to images. It seems cleaner and I am currently leaning. While this seems functionally good, conceptually I don't know if it's appropriate for an object with some significant metadata as parent.
Option 3 . Instead of an abstract parent, create a separate new "metadata" object that is "Entity A" minus the image relationship and add a "one to metadata" relationship from both "Object A" and the image object, for example creating a composite object. This seems conceptually appropriate since metadata is just one aspect of core entities, not a determinant (as it has with option 2). It also stores the image object and "Entity A" in separate tables and should be able to perform metadata searches more efficiently. The only drawback, if it is alone, is that it takes most of the attributes and relationships for "Entity A" and the image object and binds them as relationships.
Option 4 . Ignore the similarity in the attributes and just make the image object completely split by duplicating all the attributes from "Entity A". This seems to be the least desirable due to the duplication of effort.
source to share
I ended up with option 3 (creating a new metadata object) and then creating two separate metadata sub-entities to handle the inverse relationship for Entity A and the image object. This seemed to be a suitable way of doing things in terms of the object hierarchy. I've also added accessors to "Entity A" and the image object as a convenience for passing calls to the metadata entity attributes.
The resulting master data migration required a few steps and some custom encoding - perhaps more work than just creating an empty database and manually repopulating it, but it was a good learning experience with the migrations.
After finishing the migration, I confirmed that I had read about sub-entities sharing a table with a parent. In the case of the metadata object, this meant that each row had columns representing the inverse relationship for both "Object A" and the image object. For reference, the metadata table had the following columns:
Z_PK = row index
Z_ENT = entity index to distinguish between sub-entities (all entity indices are in the table Z_PRIMARYKEY)
Z_OPT = count of writes for the given row
Zxxxx - columns for each attribute and to-one relationship in the parent and sub-entities, apparently ordered with booleans first, then integers, then relationships, dates, and finally strings (from smallest to largest data size)
Note that many relationships are handled in separate tables.
source to share