I'm developing a framework that actually works with Core Data. Among the needs for implementing my framework in your Core Data class is the fact that any entity you need to possess the Framework's abilities will have to be sub organizations and sub classes of the entity Provided for you. With regard to i will call that object Foo.
Today I recognized that Core Data stores all objects which are sub organizations of Foo right into a table known as ZFOO. I am concerned about the performance of Core Data if a person with massive data sets really wants to utilize it, since ALL sub organizations from the foo class is going to be store in a single enormous ZFOO table.
Any opinions or recommendations could be highly appreciated.
This past year I done a task that did exactly the same factor, we saved my way through core data and my way through core data inherited from one class which in fact had some common characteristics.
We'd approximately 1k - 10k records in core data and gratifaction degraded to the stage where we rewrote it and removed the most popular ancestor. When I recall simple searches had to have multiple seconds, and insertions / updates were pretty crappy too. It had been only after things had become shateringly slow that people cracked the db open and observed underneath the covers core data was storing my way through one table.
Sorry I do not remember specific amounts, the large takeaway was we needed to redo it since it was not fast enough, and never not fast enough like not fast enough for top frequency buying and selling but not fast enough such as the application crashed on load when attempting to populate the first view from core data.
So, using the touch of suspicion this was on older iOS and older hardware, I'd say certainly don't do that.
I labored with @deathbob about this project because the iOS lead. Within our instance I'd multiple classes which contained the characteristics "remote_id" and "remote_update". I initially set the tables up using subclasses. I'd a "RemoteEntity" abstract entity which contained individuals characteristics and a lot of other organizations which inherited from this, each using their own. I thought that people would finish track of a lot of tables each with remote_id, remote_update, after which their custom characteristics. Rather we wound up using the massive table you describe.
The fix was really quite simple you must not setup inheritance with the GUI. Rather include all characteristics for your object as well as your shared ones within the Core Data modeller (what this means is "remote_id" and "remote_update" can look in each entity. That being stated we are able to still make use of a subclass. After producing your models' classes, produce the parent entity's class. This must not maintain the GUI. It will inherit from NSManagedObject as well as in the .m file the qualities should use @dynamic rather than @synthesize. Now that you've got parents class it's time to adjust the kid classes. Set parents class to RemoteEntity (during my example) rather than NSManagedObject. Then remove any qualities that come in your super class (during my example, "remote_id" and "remote_update").
Here's a good example of my super class https://gist.github.com/1121689.
I really hope this can help, hat tip to @deathbob for pointing this out.