Spreadsheet-like application using Core Data?

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 not implementing this especially with Core-Data, i did something which is something alike using Java and Hibernate in a web-based application.

Core Data is quite fast, if you can predict which data you require to display (which also counts for hibernate). Therefore you should seperate your view from your model and your background database to cache available data and fetch reuired cells using coarse grained operations.

This coarse grained access to the database might result in fetching the whole information network into the model if a lot of dependency exists in the model. Currently i do this using a multilevel companies balance where any access to the application simply fetches the whole datastructure into the memory.

Answer 2

I did a (fairly naively-implemented) Core Data spreadsheet-like app using Cocoa Bindings to an NSTableView and found the performance unacceptable once it got up to about 20 rows and 20 columns. But it was my first-ever Cocoa project and didn't (and to a large degree still don't) know the first thing about optimizing Core Data.

You can download and try out the app here:

http://frankschmitt.org/projects/checkpoint

and I could send you the source if you're interested (contact info on that site).

Answer 3

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.