Question

I’m working on an application which big part will be a spreadsheet-like view (with numeric values despite of columns’ and rows’ names). Is there any sense in using Core Data in such a case? I’m worrying about efficiency since I know that Core Data doesn’t natively support arrays and I don’t feel relationships would fit very well in my case. But maybe I’m wrong?

Answer 1

While Core Data is very quick with fetch requests using the SQLite store type, one thing that will slow you down is all the -valueForKey/Path: calls to get at the values of your data points (your cells) once they’re realized objects (ie, querying the DB is blindingly fast, but faulting objects in and querying their properties once they’re in is much slower).

Don’t underestimate the weight of fifty thousand of these calls, especially where sorting and display are concerned. There are a few different ways to represent this in a managed object model, but they all suffer the same issue and have various tradeoffs in terms of performance that equal out to “not fast enough” for tracking individual cells in an arbitrarily-sized matrix. If you always knew your spreadsheet would have, say, 30 columns, the problem is greatly simplified … but that would be a fairly poor spreadsheet. 🙂

Even if you used a lot of caching (such as the “The Pre-calculated Get” method mentioned in the docs), you’re only shifting the burden onto the memory, which may not stand up very well on different machines.

My recommendation would be to leave Core Data out of this one.