In Chapter 6 the example for complex mapping model the example uses a parent entity of Attachment so that the entity inherits attributes from the parent. I was giving this some thought and wanted to ask opinions on using this method v creating a separate entity with a relationship. Are their pros/cons to one approach over the other? in the example there is an attachment entity that has attributes that are shared by all attachment types. I have historically accomplished the same thing by using a relationship from what I would consider the parent entity (attachment in the book example) to the child entity (Imageattachment in the book).
I can see how that would be equivalent for one type of attachment, i.e. an image attachment.
I don’t see how it would work if you were going to support three types: images, videos, and and audio files. You would need three different relationships, one for each type. You would need to be sure to use only one relationship for each attachment instance.
By using the parent entity approach, you can have a single list of attachments of different types (polymorphism). In the underlying data store, this may be implemented with multiple tables and relationships, but as Core Data, it can be presented as a single list of attachments of different types. Core Data will take care of creating the right class object for each instance.
If your object model is going to use inheritance, you will probably want the core data model to use a parent entity to mirror that.
sgerrard, yes I would have as many relationship as I would have separate entities. So my Attachment entity would have a relationship to say ImageAttachment , VideoAttachment, audioAttachment etc. in the case of for example a video the relationship for Image and audio would be nil and vice versa.
It might end up being identical under the hood I should look at that to see when to use which method or if I should use the parent entity approach going forward. I like the idea of not having to maintain all the relationships but I didn’t know if there was any cons to the approach/
Ok I dug into this a little bit more by looking under the hood to see what Core Data was doing. Here is what I am seeing
In CoreData I created a model with a entity called Parent and two children, 1 called child and another called person (yeah ok could have been more creative). Here is what the model looks like in xcode.
You with me so far, here is the result within SQLLite using SQLBrowser to look under the hood
CoreData creates 1 table that includes the fields from all the child tables, here are the records in the table
So here are my thoughts,
I normally split up the entities specifically to reduce the size of the tables and not have empty fields everywhere, using the parent child relationship does not accomplish this and I see this getting messy with null fields everywhere especially the more child tables are added.
In my case I think I will continue to have separate entities with relationships to avoid this, I imagine depending on the number of records in the table this also makes a difference performance-wise though I didn’t test this as I do not have a table large enough.
Does my thinking make sense? Any one have any thoughts? I think this leads me to think that performing a normal normalization still is the right thing to do except if I am making a app that will not maintian many records then using the parent child relationship makes it easier to manage.
A quick update, I thought I would try to set the parent as a abstract entity, whats interesting is that it has makes no difference at the table level it still creates a parent table that has all the fields of all the children. I wonder if the compiled model uses it differently, not sure.
I don’t know much about SQLLite. Some databases, anyway, will not use much space for null values, if the table is not using a fixed record size. I’m a bit surprised that it is laid out that way, though. Were the other 3 tables just system stuff?
Yes the other three tables were system generated, always created for every app. Your point is well taken related to NULL’s and that might be the case. What really surprised me was that in the case where I made the parent an abstract entity that at the table level it treated it no different than a parent entity.
Anyways just wanted to share my findings in case anyone could use the information.
