views:

683

answers:

4

Coming from a non-SQL background, I've been having a hard time absorbing SQLite3 for the past few days. Has anyone had any good results using any of the SQLite3 wrapper APIs out there? Do they work reliably? Which is best? I am also hearing buzz about Core Data coming to the iPhone. Not sure whether that info is trustworthy or not but maybe some of you know: will there be a Core Data for the iPhone at some point?

+2  A: 

Why not target CoreData using the 3.0 SDK?

If for some reason you need to support 2.x, you should look at SQLitePersistentObject. It's slow and has some bugs but it is VERY easy to use. Sadly it is no longer under active development by the author.

Roger Nolan
Yes, I will check out Core Data for 3.0, thanks.
RexOnRoids
+3  A: 

If you're only just starting now, I would use Core Data.

I spent some time last year looking at the various wrappers at the time. I didn't use any of them in the end.

I think the NDA was still in place when I was looking so I may have missed the best ones, but I found that most were very thin wrappers. For my purposes this meant that it added an external dependency, didn't save much typing and I would probably still have had to dive down to using sqlite function calls sometimes anyway. Just didn't seem worth it.

Stephen Darlington
Thanks for your comment. I agree with you about wrappers maybe not being worth the trouble of extra installation and learning.
RexOnRoids
I have never used Core Data but I have extracted data from Core Data sqlite databases. IMHO the schema is an absolute mess and it is definitely not relational. It looks like a serialized object graph with lots of duplication, etc. Maybe the app authors didn't know how to use Core Data but my impression is that it's not so much a DB wrapper as it is an object persistence framework that happens to use/abuse sqlite for data storage. Perhaps someone with better knowledge can weigh in on pros/cons of Core Data.
Samuel Danielson
+1  A: 

Additionally: Some time ago, with a small sample project (2.x) I used fmdb. As far as I remember it was pretty easy to use. However, it required SQL knowledge.

Ushox
+3  A: 

FMDB is easy to use and abstracts some of the SQLite nastiness away from you, but still exposes the SQL.

I have used it in a project, but subclassed it to add my own partially-OO layer. The advantage of this approach is that if I need more speed or something I did not foresee (triggers for example), I can make it happen. With Core Data, there is no "bypassing" available and I have to rely on Core Data's optimizations, memory use, etc.

Another difference is the Core Data will allow your app to remain fully OO. With FMDB or other database solution, you're always tied closely to the organization of the database. It's a design decision, and not one you can change later.

Steve Weller