Data Persistence Methods

[John Black]

Hi all, i have a dilema choosing which method i will use to include data persistence for golf scorecard my application. For my application i need to create two separate data structures one to store an in depth breakdown of a players score as well as one to store course information. I know plists, SQLite3 and Core Data can be used to do this but which one would be the easiest to implement i.e. save to and load from.

Thanks for any suggestions

[Conor Winders]

Haven't used Core Data at all but have heard good things. Personally I'm a huge sqlite fan. If you have any experience with databases at all it's a complete breeze

[John Black]

i have a good bit of experience using sql but not much in a programming environment i have done some in java and remember it being a total pain to get things to work the way they are supposed to. I have seen some sample code and it looks very confusing with all the error catching. Are there any tools that you can at least view the contents of the sqllite tables you are working with? Thats my only reason for leaning towards core data with it you can at least make sure that the tables have been created correctly.

Conor Winders said:

Haven't used Core Data at all but have heard good things. Personally I'm a huge sqlite fan. If you have any experience with databases at all it's a complete breeze

[Conor Winders]

AFAIK there is a plugin for Firefox to do it, but I just use Terminal myself as I quite like it.
The other awkward thing actually is the database you develop gets *copied* into the Simulator/Device as opposed to moved so the changes you make aren't visible back in the original DB in Finder

[Daniel Heffernan]

If you only have hierarchical relationships then plist is the way to go. If you need to search data and have more complex relationships then Core Data is it. There is a *lot* more to Core Data than there is to reading/writing plist files, so I would always choose plist where possible. If your data is too much for it, then it's time to move on up to Core Data.

Generally it's not recommended you use SQL directly since 3.0 added Core Data.

[John Black]

Well a record for each of the courses and scorecard tables are going to have 20 fields and each table would have multiple records say maybe 20 each is that the right size for a plist or too big and should aim for a CoreData solution?

Daniel Heffernan said:

If you only have hierarchical relationships then plist is the way to go. If you need to search data and have more complex relationships then Core Data is it. There is a *lot* more to Core Data than there is to reading/writing plist files, so I would always choose plist where possible. If your data is too much for it, then it's time to move on up to Core Data.
Generally it's not recommended you use SQL directly since 3.0 added Core Data.

[Conor Winders]

Daniel Heffernan said:

Generally it's not recommended you use SQL directly since 3.0 added Core Data.

By whom, and why? Was planning on looking into Core Data anyway but perhaps I should move that up my list of priorities...

[Damian OSuilleabhain]

I learned Core Data for my most recent project [TBA]. There is a bit of a learning curve but it is so worth it. Its much easier than working with SQLite and it's godforsaken old school syntax. It does loads out of the box easily and using NSFetchedResultsController you can very quickly wire your data up to your UI. Only downside is you cant compile for OS 2.2.1 anymore. Anyhoo I love it and have no intention of going back to SQLite.

[John Black]

Cheers Damian i have been studying the syntax for Core Data and it does seem a bit more straight forward than using SQLite bar the managed objects that you have to create but i think i will give it a go anyway as it seems to be the method that apple want developers to lean towards.

[Daniel Heffernan]

Conor: I tried to pull up where I read that but can't find it.

john: It sounds like Core Data is huge overkill if that's the case. You're talking about 2 arrays with up to 20 dictionaries contained in each. Easily serialised to/from plist and very very lightweight.

[Mark Goody]

I don't know how officially it's been said, but I read several times on the dev forums where Apple staff recommended always using Core Data over directly using SQLite. (Presumably assuming targeting 3.0+.)

I wonder if anyone's done a performance comparison?

Once you factor in the all extra goodness in NSFetchedResultsController (especially the automatic batching and faulting to keep the memory usage down), I reckon I'd need to hear a pretty strong argument in favour of directly hitting SQLite.

[Daniel Heffernan]

Plus, SQLite is a C API and Core Data is totally Objective-C, which is certainly a big thing for me as I'd end up wrapping SQLite in custom objects anyway. I'm sure lots of others here would end up doing the same.

[Vinny Coyne]

If you decide to access SQLite directly, there's a really useful wrapper called FMDatabase: http://code.google.com/p/flycode/source/browse/trunk/fmdb

Core Data is great for more complex data models, but hardcoding data into it (so that it's there on first launch) can be a bit of a pain.