Core Data VS Sqlite or FMDB....?

Question

Now this might look like a duplicate thread, but my question is that I have read a lot of questions like.. Core Data vs SQLite 3 and others but these are 2-3 years old. I have also read that FMDB was developed as core data was not supported on iOS, So it should not be used any more. And on the other hand I have read that one should not use core data as a database.

So I am seriously confused,whether I should use core data for object storage or not. I mean on what basis I should decide which to use? Are there any guidelines provided by apple or someone else.. or is it something that will come to me with time.?

Pages

What data are you storing, how much of it is there, what sort of retrieval do you need to do, is it editable by the user? – Nika

That's what my question is .. I mean on what basis I should decide which to use and are there any guidelines provided by apple or someone else.. or is it something that will come to me with time.? – Pages

If you need to update, insert, or delete many rows at once, then Core Data won't be a good choice. – Bohn

@Toro And is it because it takes more time or memory in comparison to sqlite? – Pages

For example, if you want to delete all rows in Core Data, you need to delete one by one. But with sql syntax, it is just only one command. – Bohn

You can read following post. https://mcmap.net/q/98993/-core-data-vs-sqlite-3-closed In the SO post, a link On switching away from Core Data will bring you to the following url. Core Data is powerful, but it has some constraint. inessential.com/2010/02/26/on_switching_away_from_core_data – Bohn

@AnkitSrivastava : basically many of our friends answer your question but just want to say you that "Core Data is used for managing the database in object form thats means you make the model class that help you to interact with database in object terminology thats it." its my view that i express with this comment, may be this question is already clear to you but i make a comment here for others views, hope so you getting my point :):) – Fascicle

Answer 1

Ankit,

Here's the tl;dr skinny: use Core Data.

Here's the long form:

While you could use many criteria to choose between Core Data, an ORM (FMDB) or direct sqlite calls, the real cost of this choice comes from your time to use it, Apple's support and leverage from other projects. (RESTKit, which maps REST services on to Core Data, is popular these days.)

Hence, a large percentage of the time, say 90+% (a made up stat), the answer on iOS will be to use Core Data. Why? Once you get the hang of it and build out a few little helper methods, Core Data keeps you in a consistent computing world -- the Objective-C object graph. Core Data will teach you things about how to use a dynamic language that will help every other aspect of your iOS programming. Hence, you are more productive. Don't fight the framework.

If you are bringing over a large, complex SQLite database & schema from another app, it then might be cost effective to use either FMDB or SQLite. But I doubt it. Your time writing a simple Mac-based command line app to migrate the DB to a Core Data DB is a finite and simple task. You are almost guaranteed to have to rewrite most of the business logic in Objective-C. (Yes, C++ and Objective-C++ are both good technologies. Has your database business logic really been tuned to work on a memory limited device? I didn't think so.)

Core Data gets a bum rap on performance. It is really quite fast. You just have to use it differently than you use a DB. In particular, you almost always over-fetch data from the store and then refine it using predicates directly on the various sets and arrays. On iOS devices, where the flash is surprisingly slow, this over-fetch strategy is particularly effective. You actually have a lot of RAM on these devices, use it to gain performance. (Yes, I know this is an apparent contradiction to my above knock on portable business logic. But really, code ported from a desktop or server environment has so many implicit assumptions about the speed of the disk, the amount of memory and the reality of a VM with a backing store, it just will not work well on a battery powered, memory limited device with a funky memory model. [It won't work very well on Android devices either.]) You will also denormalize your data to simplify displaying it in various iOS and Mac OS X UI widgets. There are a few applications where Core Data will be slower than an equivalent SQLite DB. Those have been detailed elsewhere. The one major claim is that tasks where IDs are defined by upstream databases hits Core Data's performance is true. But it can be somewhat mitigated by judicious indexing and over-fetching.

The thing to remember about mobile devices too is that the database size, because these are mobile devices on the leaves of the internet, is generally of modest size. Hence, performance is easier to attain. Many lessons from the world of servers may not apply to this mobile, battery powered world.

In other words, you've had to go "all in" to use Objective-C on iOS/Mac OS X, you will gain some important productivity benefits from using Core Data too.

Andrew

Tuttle

As the current maintainer of Jeff LaMarche's SQLite Persistent Objects, I add that FMDB is the right SQLite wrapper to use. Just because it hasn't been updated recently is not a sign of abandonment but of maturity. For example, I maintain a version of Apple's Reachability code, < blog.ddg.com/?p=24 >. I haven't made an update in quite awhile. (An update is in the works.) Why? It works well enough. Old stable code is a good thing. Andrew – Tuttle

Answer 2

I recently embarked on this journey myself, and ended up trying out all three. Here's what I learned:

• Raw sqlite3
  • Low-level, full access to database. No abstractions. Very verbose - it takes a good deal of code to do very simple things.
• Core Data
  • Very high-level, built on abstractions, MUST use Apple's generated database. Useful for iCloud synchronization and simple iOS-only data management. Difficult and dangerous to directly access database, and should not be used for cross-platform databases. Still takes a fair amount of code to do simple things.
• FMDB
  • High-level, very abstraction friendly but not forced. Still get full access to database if you need it. Provides an NSDictionary of the result with each item automatically typecasted to the mutable variant of the proper datatype (e.g., text columns are returned as NSMutableString). I ended up building a very simple wrapper class around it to abstract it even more, so I have a helper class with static functions like selectAllFrom:(NSString *)table where:(NSDictionary *)conditions, which returns an NSArray of NSDictionary objects. It's fantastic to be able to do things like NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];.

Basically, while Core Data may be useful for simple iOS-only apps, anyone who's interested in using cross-platform databases should stay far, far away from it - Apple has no interest in making that easy, and it shows.

---

TL;DR:

• Don't use raw sqlite3 unless you're doing something extremely trivial.
• Core Data is fine for simple iOS-only data, if you're comfortable with being locked into it.
• If you want full control over the database and you're not doing something trivial, or you're building your app for multiple platforms, FMDB is definitely the way to go.

Protuberance

Answer 3

I use FMDB for all my projects that have heavy usage of "INSERTs" and FMDB is not out of date. The last commit on Github was at last November. If you go with SQL I recommend you to use FMDB.

Core Data fits to 95% of all projects, but if it comes to optimization to run to a wall. If you want the benefits of Core Data (OOP, ...) then use it. If you have a lot of insert an deletes with "WHERE" user Sqlite (FMDB)

This POST explain the off and top site for Core Date vs. Sqlite (FMDB)

Swamper

I don't understand why use a wrapper instead of using directly Objective-C sqlite3 functions. I generally use Core Data for model design purposes. – Slipknot

simply: its easier to use! And you dont handle the sqlite "lock" state by yourself, its thread save, Pattern Matching, you can use normal Foundation Object and your code is cleaner. (FMDB )6 lines of code vs. 10++ lines of code with sqlite – Swamper

I think your code is a lot cleaner with Core Data and most importantly easy to mantain (by doing reverse engineering). – Slipknot

yes, you are correct. But if you have heavy usage of "insert" and "SELECT 1 FROM" and "DELETE FROM TABLE WHERE .." you should use sqlite for the speed profit! – Swamper

If speed is your objective you're right, generally we use to target maintainability. – Slipknot

@Swamper Can you have any idea for this question #18974148 – Zigmund

Answer 4

CoreData is not just an abstraction of an SQL database. CoreData is also does object graph management. CoreData can do things that FMDB simply can't do.

As always: It really depends on your use case. But in 99% of cases CoreData is the right choice.

If performance is critical, you still have to understand how a database works. But CoreData can deliver that performance if you use it the right way. But it takes some time to learn. There are many things that are trivial to do in CoreData that would be very complex to do in FMDB.

Louls

"But in 99% of cases CoreData is the right choice." this is such a bold statement. Can you justify with facts please? – Munguia

Answer 5

As a new SQL guy, I'm going to throw in my two cents:

In Core Data, you have a bit of "boilerplate" code that you need to put in before you can actually use your database. Your app needs at least one of these:

1. A persistent store coordinator
2. A managed object context
3. A managed object. This correlates to an entity, which correlates to a table if you use an SQLite database.

To take full advantage of the framework, you need to understand what role these objects play in the management of your data.

On the other hand, we have SQLite, which - in my opinion - is much easier to understand. To start, you'll need:

1. A database
2. A table or more (depending on your data)
3. Knowledge of SQL - a flexible language with a simplistic syntax (SELECT queries do more than what you might originally think they do)
4. An object through which your app communicates with SQLite.

Stereophotography

Answer 6

Core Data is only an object abstractization of the SQLite3 database. That means you'll have persistant objects easy to manage for standard database operations. You can also work in an transactional mode and design your core data database structure in XCode by creating models.

If you don't whant to create manually your SQLite3 database or persistant methods use Core Data.

Slipknot

So can we rule out FMDB completely? – Pages

I think FMDB was used because Core Data hasn't been available in iOS < 3.0 – Slipknot

core data isnt a DATABASE: cocoawithlove.com/2010/02/… . Core Data use a Database eq Sqlite to store the data. – Swamper

I have to agree with @meccan that Core Data offers considerably more than what you seem to be implying here. – Tournedos