3

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 ?

AirXygène
  • 2,409
  • 15
  • 34

3 Answers3

2

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.

Community
  • 1
  • 1
Willeke
  • 14,578
  • 4
  • 19
  • 47
  • Thanks ! And I like very much this simple explanation : "I think the only time that entity inheritance is absolutely required is when you need different entities to show up in the same relationship". – AirXygène Apr 30 '16 at 18:27
1

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.

Joride
  • 3,722
  • 18
  • 22
  • 1
    Mmmmh... not sure. From Apple's doc : "Be careful with entity inheritance when working with SQLite persistent stores. All entities that inherit from another entity will exist within the same table in SQLite. This factor in the design of the SQLite persistent store can create a performance issue." (Creating Managed Object section of Core Data Programming Guide) – AirXygène May 13 '16 at 05:52
1

I've been working on a project with one base entity for around 20 subentities and easily overall 50k instances for over 2 years now. We've never had performance problems with selects, inserts or updates.

The keys to using Core Data inheritance with large data sets are

  • optimized fetch requests (tune predicate, exclude irrelevant properties, prefetch relationships, omit subentities, set fetchLimit, use dictionary result type or count-requests if sufficient etc.)
  • batch saves (meaning not saving the MOC after every insert etc.)
  • setting up proper indices (they can speed up selects a looot)
  • structuring your UI appropriately so you won't have to load and display many thousand objects in one viewController

We do not even use parent/child managedObjectContexts or private queues (which introduce a lot of extra complexity on their own) when importing JSON, as our data model and mapping code is so highly optimized, that the UI doesn't even flicker or hang considerably when importing a few thousand objects.

Sven Driemecker
  • 3,421
  • 1
  • 20
  • 22