iPhone 3.0 support the Core Data, it seems a great tool for developer. But SQL statement seems it is easier to get start, but core data is easier for maintaining db. But I'm considering the SQL statement, because it seems have better performance. I am consider which one is better for iPhone development, any suggestion?
A:
This provides a reasonable list of the pros and cons of either approach: http://maniacdev.com/2009/09/iphone-sqlite-vs-core-data-–-which-to-choose/
The recommendation is to use Core Data as it makes things so much easier in the long term.
Petesh
2010-02-18 14:24:20
A:
There is an in-depth explanation of the differences between the 2 here: http://cocoawithlove.com/2010/02/differences-between-core-data-and.html
That's a great read. The 2 approaches are different and both have their pros and cons.
Zoran Simic
2010-02-18 15:02:34
+4
A:
The answer is actually much simpler than either of those blog posts make it appear. The rule is:
- If you are developing for any OS X platform;
- If you are not accessing a proprietary format; and
- If your persistence file does not need to be read on a non OS-X platform
Then you should go with Core Data. It is that simple. Core Data gives you so many features and the ease of use compared to straight SQL makes the choice simple. As far as performance, that is a red herring. Where it counts, Core Data can and does easily out perform custom code accessing a SQLite database. However, performance on Cocoa Touch is actually a secondary concern.
The primary concern is memory. You have a tiny amount of memory in which to work with on Cocoa Touch and your data model can easily blow that out. Core Data solves that issue. It watches how much memory it is using and will drop objects out of memory automatically when it receives a memory warning. All of that fairly complex code you would have to write yourself if you used SQLite directly.
Less time coding your data model means you have more time making your application great.
Marcus S. Zarra
2010-02-18 16:52:48
My expectation would be that SQLite would *always* use less memory than Core Data, even after Core Data's memory warning. SQLite's page buffer is in memory with either technology, but SQLite doesn't store any additional objects in RAM. Is this untrue?
Steven Fisher
2010-02-18 17:00:29
You are thinking of just the SQLite library. But you have data structures around the SQLite library and those are the trick. With SQLite you have to manage those yourself, watch for memory, handle caching, etc. All of that is very complex and easy to get wrong. Even if you get all of that right, in the end you end up with a poor imitation of Core Data. Easier and faster to go with the original and get free upgrades instead.
Marcus S. Zarra
2010-02-18 17:14:17
It is counterintuitive, but things like batched fetching (enabled with one line of code in Core Data) can lead to a tremendous memory and performance win. It would take a lot of code for you to reproduce this with bare SQLite. If Apple has switched their on-device applications to Core Data over SQLite, you know there have to be performance advantages.
Brad Larson
2010-02-19 14:15:20