Core Data sqlite store single table due to inheritance drawbacks?

Question

I have a Core Data model with something like 20 entities. I want all entities to have common attributes. For example, all of them have a creation date attribute. I therefore introduced an common entity containing all the common attributes, and all the other entities inherit from this common entity.

This is fine and works well, but then, all entities end up in one single SQLite table (which is rather logical).

I was wondering if there was any clear drawback to this ? For example, when going in real life with 1000+ objects of each entity, would the (single) table become so huge that terrible performance problems could happen ?

Answer 1

This question has been asked before:

Core Data entity inheritance --> limitations?

Core data performances: when all entities inherit from the same parent entity

Core Data inheritance vs no inheritance

Also keep in mind that when you want to check the SQLite file for debugging purposes, seperate tables are easier to examine.

I would use a common NSManagedObject subclass instead of a parent entity.

Answer 2

Don't worry about this. From Core Data documentation:

https://developer.apple.com/library/tvos/documentation/Cocoa/Conceptual/CoreData/Performance.html

... The SQLite store can scale to terabyte-sized databases with billions of rows, tables, and columns. Unless your entities themselves have very large attributes or large numbers of properties, 10,000 objects is considered a fairly small size for a data set.

What is way more important is that if you are doing any heavy operations, like fetching a lot of objects, or parsing objects based on some JSON from a webservice, you do this not on the mainthread. This is not very hard to do, look into parent/child managedobjectcontexts and how they can be used with managedcontextobjects with a private / main queue concurrencytype. Many good blog posts about this subject exist all over the interwebs.