Does it make sense to use different CoreData configurations to improve performance/reduce storage even if using just one persistent store?

Question

I am working on a suite of apps and those apps will have a lot of model code in common. I'm using CoreData so I currently plan on having just one model file for all the different apps, although not all apps use all entities defined in the model.

I have read about Core Data configurations that can be defined in the managed object model to get only a subset of all entities. I am wondering whether I could use these to also optimize the CoreData usage in my apps.

Consider the following scenario:

I have three apps, App1, App2 and App3. They have a shared managed object model with the following entities.

A, A1, A2, A3, B, C, D

whereas A is abstract and A1, A2 and A3 all inherit from A. Each of the A1, A2 and A3 entities have around 10 - 20 attributes/relationships.

Now

• App1 only uses A, A1, B, C, D,
• App2 only uses A, A2, B, C, D,
• App3 only uses A, A3, B

I have read (can't remember where) that to model sub entities in sqlite, CoreData just creates a table for the parent entity that contains all attributes and relationship of sub entities as table columns. Therefore it would often not be advisable to create small parent-entities with several large sub-entities, since it would lead to a lot of empty columns for each of the sub-entities (which don't need the columns for attributes of other sub-entities).

Now, using configurations, I could create three configurations Conf1, Conf2, Conf3 like that:

• Conf1 contains entities A, A1, B, C, D,
• Conf2 contains entities A, A2, B, C, D,
• Conf3 contains entities A, A3, B

Each of the apps would use a single store with the appropriate configuration, so I wouldn't make use of the "store the object automatically in the correct store" advantage configurations have when used with several stores.

However, my hope is that by adding a store for the specific configurations in each of the apps, the store would ignore the attributes of the non-included entities and thus not create the appropriate table colums. In Case of App3/Conf3 it would even avoid the creation of tables for entities C and D altogether.

My questions is: Does it work that way? Would the superfluous columns be left out in persistent stores that use the correct configuration?

And if so: Does it actually make a difference in performance or storage requirements (assuming a number of objects so performance optimizations actually start to make sense)?

Answer 1

How Core Data represents sub entities in the SQLite store is an implementation detail that is hidden from you and subject to change. Do not depend on it working one way, because at some point it may work completely differently.

You may be prematurely optimizing. Build it, test it, and if there is a performance issue stemming from how you're using entities address it at that point.

As to your actual broader question wether there should be performance advantages in using multiple configurations for a single store: There shouldn't be. If you have one SQLite store and there is only one configuration, Core Data is not going to be making additional optimizations based on the (single) configuration.

Much of Core Data's performance comes from your data model design and access patterns. An application that is architected to be aware of Core Data faulting behavior that uses a well thought out data model will be quite performant. Even if you have a less than optimal data model Core Data can be very fast if you optimize your round trips to the persistent store (i.e. managing faults, batch faulting when appropriate, implementing a correct find-or-create).

The Incremental Store Programming Guide contains a very good description of how faults are fulfilled. The Core Data Programming Guide has a higher level description of faulting, and discusses batch faulting, prefetching, and the find or create pattern.