Core Data vs SQLite 3

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

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 2

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 3

The SQLite DBMS has serious problems from a relational point of view, primarily being the mishandling of all columns as strings, and not being able to handle referential integrity correctly.

That being said, it's a brilliant product for learning SQL, I just wouldn't use it for anything important.

Core Data, on the other hand, is the "next layer up". It's an abstraction which can use various DBMS' as the next layer down and it is a boon to Cocoa developers. You can start using it with various underlying data stores (including SQLite, I believe) and, hopefully, put a decent data store under it if you ever want to provide enterprise-quality behavior.

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 maintins reference integrity (e.g. keeping forward and backwards 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 managemet, 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 an complete MVC architecture with very little code.

Answer 5

This might be of interest to you. By Brent Simmons, author of NetNewsWire.

On switching away from Core Data (to SQLite)