Assuming three columns in the table: ID, NAME, ROLE
BAD: This will insert or replace all columns with new values for ID=1:
INSERT OR REPLACE INTO Employee (id, name, role)
VALUES (1, 'John Foo', 'CEO');
BAD: This will insert or replace 2 of the columns... the NAME column will be set to NULL or the default value:
INSERT OR REPLACE INTO Employee (id, role)
VALUES (1, 'code monkey');
GOOD: Use SQLite On conflict clause
UPSERT support in SQLite! UPSERT syntax was added to SQLite with version 3.24.0!
UPSERT is a special syntax addition to INSERT that causes the INSERT to behave as an UPDATE or a no-op if the INSERT would violate a uniqueness constraint. UPSERT is not standard SQL. UPSERT in SQLite follows the syntax established by PostgreSQL.
GOOD but tedious: This will update 2 of the columns.
When ID=1 exists, the NAME will be unaffected.
When ID=1 does not exist, the name will be the default (NULL).
INSERT OR REPLACE INTO Employee (id, role, name)
VALUES ( 1,
'code monkey',
(SELECT name FROM Employee WHERE id = 1)
);
This will update 2 of the columns.
When ID=1 exists, the ROLE will be unaffected.
When ID=1 does not exist, the role will be set to 'Benchwarmer' instead of the default value.
INSERT OR REPLACE INTO Employee (id, name, role)
VALUES ( 1,
'Susan Bar',
COALESCE((SELECT role FROM Employee WHERE id = 1), 'Benchwarmer')
);
Best Answer
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