iOS Native Database: Core Data Vs SQLITE--A conceptual understanding

iOS Native Database: Core Data Vs SQLITE--A conceptual understanding

The most popular iOS database alternatives are SQLite, Core Data, and Realm, a more recent competitor. This article examines the advantages and disadvantages of each choice as well as how to convert from Core Data or SQLite to Realm. The most popular open-source database engine in use today is SQLite. It utilizes a transactional SQL database engine without the need for configuration or a server. Mac OS X, iOS, Android, Linux, and Windows all support SQLite. Because it is designed in ANSI-C, it provides a straightforward and user-friendly programming interface. Additionally, SQLite is incredibly compact and lightweight, and the entire database may be kept in a single cross-platform storage file.?

The following are the causes of SQLite's enormous popularity:

Independence from a server

Zero-configuration

Safe access from multiple processes and threads

data is kept in tables with one or more columns that each carry a particular kind of information.

The second most important iOS storage technique accessible to app developers is Core Data. Both SQLite and Core Data offer advantages and disadvantages depending on the kind and quantity of data you need to manage and store. Compared to conventional table database systems, Core Data places more emphasis on objects. By using Core Data, you are saving the contents of an object, which in Objective-C is represented by a class. Although they diverge fundamentally, Core data:

Uses more memory than SQLite

Uses more storage space than SQLite

Faster in fetching records than SQLite.

A Real-Life Example: 10,000 Items

Picture an RSS reader. The Mark All As Read option is available when a user right-clicks on a feed.

There is an Article entity with a read attribute hidden inside. To mark all items as read, the app has to load all of the articles for the feed (probably via a to-many relationship) and then set the read attribute to YES.

Most of the time that’s okay. But if that feed contains 200 articles, you might think about executing this task in a background thread so you don't obstruct the main thread. (especially if the app is an iPhone app).?

Things become challenging as soon as you work with multi-threaded Core Data.

It's probably not worth switching away from Core Data, or at least it's not that horrible.

But then add syncing.

I used two different RSS synchronization APIs that produced arrays of unique ids for reading articles. One of them gave up to 10,000 IDs back.

You won't load 10,000 articles onto the main thread and turn off the read. Even with strict memory management, you don't want to load 10,000 articles in a background process. It’s just too much work. With SQLite, you can do that. With one call. And, assuming an index on unique ID, it’s fast. And you can do that just as simply on a background thread as on the primary thread.

Basic Operation

I've been using SQLite long before Core Data and iPhones. The basic principles are as follows:

All database access, including reading and writing, takes place on a background thread serial queue. It is never permitted to hit the database on the main thread. Everything happens in the correct order when using a serial queue.

I heavily rely on blocks to make async programming easier. Model objects are only present on the main thread (with two important exceptions). Changes trigger a background save.

Model objects list their database-stored attributes.

Some model objects are unique and some aren’t. It depends on what the app needs. (They’re usually unique.)

I try to create lookup tables for relationships as little as possible.

At startup, some object types are completely read into memory. To know what exists and what doesn't without having to access the database, for other object types I might establish and maintain an NS MutableSet containing simply their unique ids.

Web API requests utilize "detached" model objects and run in background threads.