Database Reference
In-Depth Information
4.2
Optimizing Your Data Model
When we design our data model, we need to consider several factors. Where
we put our binary data can be extremely important because its size and
storage location plays a key role in the performance of our application. Like-
wise, relationships must be carefully balanced and used appropriately. Also,
entity inheritance, a powerful feature of Core Data, must be used with a del-
icate hand because the underlying structure may be surprising.
Although it is easy to think of Core Data as a database API, we must
remember that it is not and that structuring the data with data normalization
may not yield the most efficient results. In many cases, denormalizing the
data can yield greater performance gains.
Where to Put Binary Data
One of the easiest ways to kill performance in a Core Data application is to
stick large amounts of binary data into frequently accessed tables. For
example, if we were to put the pictures of our recipes into the recipe table,
we would start seeing performance degradation after only a couple hundred
recipes had been added. Every time we accessed a
Recipe
entity, we would
have to load its image data, even if we were not going to display the image.
Since our application displays all the recipes in a list, this means every image
would reside in memory immediately upon launch and remain there until the
application quit. Imagine this situation with a few thousand recipes!
But where do we draw the line? What is considered a small enough piece of
binary data to fit into a table, and what should not be put into the repository
at all?
If you are developing an application that is targeting iOS 6.0 or greater (or
Mac OS X 10.8 or greater), the answer is simple: turn on external binary
storage in the model and let Core Data solve the problem for you (see
Figure
13,
Turn on the external record flag
, on page 64
). This feature instructs Core
Data to determine how to store binary data. With this flag on, Core Data
decides whether the image is small enough to store inside of the SQLite file
or whether it is too big and therefore should be stored on disk separately. In
either case, the decision is an implementation detail from the perspective of
our application. We access the binary data just like any other attribute on
the entity.
If the application is still targeting an older version of the operating system
(iOS or Mac OS X), then the application is responsible for dealing with binary
data in a performant way.
