Database Reference
In-Depth Information
Denormalizing Data to Improve Performance
Although the most powerful persistent store available for Core Data is a
database, we must always be conscious of the fact that Core Data is not just
a database. Core Data is an object hierarchy that can be persisted to a
database format. The difference is subtle but important. Core Data is first a
collection of objects that we use to display data in a user interface of some
form and allow the user to access that data. Therefore, although database
normalization might be the first place to look for performance improvements,
we should not take it too far. There are six levels of database normalization,
1
but a Core Data repository should rarely, if ever, be taken beyond the second
level. There are several cases where we can gain a greater performance benefit
by denormalizing the data.
Search-Only Properties
Searching within properties can be quite expensive. For properties that have
a large amount of text or, worse, Unicode text, a single search field can cause
a huge performance hit. One way to improve this situation is to create a
derived attribute based on the text in an entity. For example, searching in
our description property of the
Recipe
entity can potentially be very expensive
if the user has verbose descriptions and/or uses Unicode characters in the
description.
To improve the performance of searches in this field, we could create a second
property on the
Recipe
entity that strips the Unicode characters from the
description and also removes common words such as
a
,
the
,
and
, and so on.
If we then perform the search on this derived property, we can drastically
improve search performance.
The downside to using search-only properties is that we need to maintain
them. Every time the description field is edited, we need to update the derived
property as well.
Expensive Calculations
In a normalized database, calculated values are not stored. It is considered
cheaper to recalculate the value as needed than to store it in the database.
However, from a user experience point of view, the opposite can frequently
be true. In cases where the calculation takes a human-noticeable amount of
time, it may very well be better for the user if we were to store that calculation
in the entity and recalculate it only when one of its dependent values has
1.
