A few people have wrapped the SQLite library or provided alternatives. What are their relative merits?
+4
A:
Yes, a bit of snarky answer.
There are three primary reasons to use SQLite directly or via a wrapper.
You are sharing databases across platforms and can't use Core Data's schema
You really do need raw SQLite performance and have the 17th level SQLite API Mastery required to actually achieve said performance advantage over SQLite.
You know SQLite inside and out, don't like learning new things, and want to re-invent the bits necessary to get between database and screen. (Slightly snarky again).
Core Data buys you a tremendous amount of functionality that is subtly very hard to do. That is, object graph management with full integrity and undo support.
bbum
2010-08-12 04:44:23
Technically Core Data is not an SQLite wrapper, it's an object graph management framework that happens to use SQLite (optionally) for persistence.
alexantd
2010-08-12 05:04:57
This is a smartass, non-answer. If you want an object graph that's not SQLite-like, it's a good choice. But it's not a SQLite library.
Steven Fisher
2010-08-12 05:11:39
Core Data is very much a SQLite wrapper. Given the wide range of features in various SQLite wrapper libraries, it certainly has a particular focus, but there are others that are quite complex, too. Snarky? Yes -- absolutely. Busted. I'm just tired of seeing developer after developer do SQLite directly (or indirectly through a library) wrong and be left w/a ton of bugs as the reward for their "roll yer own" efforts.
bbum
2010-08-13 04:26:32
I would like to chime in and add, when you're new to the iPhone platform, and have a decent understanding of RDBMS, it seems fairly obvious that an SQLite wrapper is the way to go. What is not obvious is all the facets required for app development that Core Data encapsulates and simplifies for you. While it's true that Core Data's persistent store provides some obvious limitations, you need to look further at what else it does, to allow your app to be a great citizen on the platform. Contexts, merging, faulting, etc are wrapped up in an approachable API.
ohhorob
2010-08-13 07:02:44
Okay. That's clearly improved. Thanks. :)(And no offense meant earlier, I like your other posts, that one was just a bit too snarky without explanation.)
Steven Fisher
2010-08-13 18:56:52
@tewha No offense taken -- it was completely a smart-ass answer and I deserved to be called on it. @ohhorob Yup -- exactly. Object graph management and the interface between UI and persistence is rife with subtle issues of which Core Data solves many or, at least, provides a clean foundation.
bbum
2010-08-13 22:24:59
+3
A:
bbum gave the most succinct answer and you should ponder carefully not using Core Data.
But I thought you also deserved an answer to your actual question.
There are basically two wrapper approaches I know of:
FMDB uses an approach that simply makes a much easier to use Cocoa API overlay for SQLLite. This can be great if you know SQL and database design well and just want a simple database.
Other approaches are generally more object-relational mapping systems, that attempt to give you an object view of an underlying datastore, and hide some queries from you.
In both cases if you have a really simple data store they can make sense to use if you have a specific reason... but using Core Data gives you an awful lot for free (though I'll admit the learning curve can be steep).
Kendall Helmstetter Gelner
2010-08-12 05:01:12