Core Data vs SQLite 3 [closed]

Question

I am already quite familiar with relational databases and have used SQLite (and other databases) in the past. However, Core Data has a certain allure, so I am considering spending some time to learn it for use in my next application.

Is there much benefit to using Core Data over SQLite, or vice versa? What are the pros/cons of each?

I find it hard to justify the cost of learning Core Data when Apple doesn't use it for many of its flagship applications like Mail.app or iPhoto.app - instead opting for SQLite databases. SQLite is also used extensively on the iPhone.

Can those familiar with using both comment on their experience? Perhaps, as with most things, the question is deeper than just using one over the other?

Answer 1

Core Data isn't so much a database engine as it is an API that abstracts over the actual data store. You can tell Core Data to save as an sqlite database, a plist, a binary file, or even a custom data store type.

I would recommend learning Core Data, as is it an excellent resource that greatly accelerates many parts of cocoa application development.

Answer 2

And with iOS 5.0 you get the added benefit of being able to use iCloud file-sync for free if you're using Core Data. If you're using SQLite directly it'll have to be a lot of manual tinkering and implementation to get it to sync across iCloud.

Answer 3

SQLite is one of the database formats for Core Data. Using Core Data you get better integration with the rest of the Cocoa API.

Answer 4

Although Core Data is a descendant of Apple's Enterprise Object Framework, an object-relational mapper (ORM) that was/is tightly tied to a relational backend, Core Data is not an ORM. It is, in fact, an object graph management framework. It manages a potentially very large graph of object instances, allowing an app to work with a graph that would not entirely fit into memory by faulting objects in and out of memory as necessary. Core Data also manages constraints on properties and relationships and maintains reference integrity (e.g. keeping forward and backward links consistent when objects are added/removed to/from a relationship). Core Data is thus an ideal framework for building the "model" component of an MVC architecture.

To implement its graph management, Core Data happens to use SQLite as a disk store. It could have been implemented using a different relational database or even a non-relational database such as CouchDB. As others have pointed out, Core Data can also use XML or a binary format or a user-written atomic format as a backend (though these options require that the entire object graph fit into memory). If you're interested in how Core Data is implemented on an SQLite backend, you might want to check out OmniGroup's OmniDataObjects framework, an open source implementation of a subset of the Core Data API. The BaseTen framework is also an implementation of the Core Data API using PostgreSQL as a backend.

Because Core Data is not intended to be an ORM for SQLite, it cannot read arbitrary SQLite schema. Conversely, you should not rely on being able to read Core Data's SQLite data stores with other SQLite tools; the schema is an implementation detail that may change.

Thus, there is not really any conflict between using Core Data or SQLite directly. If you want a relational database, use SQLite (directly or via one of the Objective-C wrappers such as FMDB), or a relational database server. However, you may still want to learn Core Data for use as an object graph management framework. In combination with Apple's controller classes and key-value binding compatible view widgets, you can implement a complete MVC architecture with very little code.