BLACK FRIDAY SALE: Save big on all my Swift books and bundles! >>

When to use CoreData?

Forums > SwiftUI

Hello all,

I'm having problems understanding where and when CoreData is a good choice. Maybe someone who understands this can help me out?

For example, if i want to build an app that allows users to track their habits - is CoreData a good option to store these habits and statistics (if i don't want to share it accross multiple devices)?

Or note taking app - is it also a good choice if i don't want to share notes accross different devices?

Is there a "limit" of how much data i should store in CoreData?

   

I'm going to answer this as "when to use a database vs. not a database":

  1. You need to store metadata with your notes, and you need to search on arbitrary combinations of that metadata. For a complex note-taking app where you'd have sections, to-do items, pictures (not stored in the database themselves, just a link to them is), much of the info about that could be stored in a database. I used to love an app called Backpack and would use one page (note) to keep track of travel info for a given trip, including links to PDFs of my reservations, a flight itinerary, to-do items related to that trip, and separate note sections for each planned day. I might also include some possible items (e.g., a favorite restaurant in Nice; a favorite museum in Chicago) in another section.
  2. You have different kinds of data you need to relate to each other, e.g.: people, houses, cars, and you need to search on what's related to what. Someone smooshed this parked car, who do I call?
  3. Databases take longer to write data out (because indexes also have to be created or updated), so a traditional database (which Core Data is under the hood) works best if you are reading data far more frequently than writing data. (If you need fast writes but slow reads are okay, then a nosql database is a better option.)

So basically, Core Data is about:

  • How is this item related to that item? A project may have multiple tasks; a task may have multiple ToDo items. That hierarchy of one-to-many items is a classic database problem.
  • Is there a complex relationship between items? E.g., a car can be owned by two people, each of whom can own more than one car, and possibly more than one house. (two many-to-many relationships)
  • Sometimes, databases are used to bridge data from disparate sources: you have API A and API B from different sources, and you need a way to say this item from A is the same as that item from B.

1      

Like almost everything else in programmin it depends. CoreData has plusses, it has minuses. You need to understand your situation, the plusses of CoreData, the minuses of CoreData, the plusses and minuses of other solutions.

That was very unhelpful for you. For your example CoreData has a bunch of plusses. Handeling the storage of the data is built in. Define you data to CoreData, just like you would have to do no matter what you use, and it will handle everything. It will generate classes to define your data that you can use in your app. Just call it and say you want to load and it handles the whole thing, finds the data on the iphone, reads it in, has it for you to use. One call and it writes it back out, your app updates/adds/deletes and then makes one call and everything is written back.

Now a limit on the amount. The device you run on has limmited storage, my iphone has 128 GB so CoreData will run out of space. Also, I have other apps that use some of that space. Also, the phone will tattle on you and tell me how much storage you are using and if I think it's too much I will be unhappy. Now, this part I am not sure of but I am pretty sure that CoreData reads all the data and keeps it in memory while it is being used. I could not find an explicit discussion of this and I am not sure how the iPhone handdles paging, but you might be limmited to using the ram on the phone. However, a Gigabyte of storage is a LOT. The first mainframi I worked with did not total 1GB if you added the ram, the 4 disk drives, and 2 tape drives.

The downside, for me, is that it is a black box. I like to know how a couputer is doing the things I ask it to do. It can also be a problem if you want to do something that it is not designed to do. It is easy to do A cause it supports it but, if you want to do B then heaven help you. It might be tough to to B or it might be impossible. And CoreData might be a fantastic fit for an app, but if there is one small thing that is impossible then you can't use it.

It is hard to underestate what it is that CoreData magically provides for you. Just reading data from disk can have a bunch of errors. and problems and CoreData handles all that with a single indtruction. There are problems of referental integrity, CoreData handles it. Journaling, undo, etc. CoreData will do it all.

CoreData is not light. It adds a lot of processing to somple tasks. This offends me. It should not. On a devide that is capable of billions of instructions a sedond what does it matter to a user if something takes 1,000 instructions or 100,000.

Bottom line, if CoreData will do what you want you can save a LOT of time and bugs by using code already written rather than writing your own. From your description CoreData will do what you want for both applications. Unless you ara a masochist, or enjoy sabing a few instructions, or don't like black boxes, use CoreData. It's easier to figure out CoreData than figure out how and then write your own data handler.

1      

@p7willm and @deirdresm,

Thank you very much for the detailed explanation, now it makes a lot more sense to me.

   

CoreData is not light.

I'm going to quibble with you on that statement, @p7willm. Yes, you're right, if you're used to the economy of, say, being a C programmer, it's not.

However, as someone who's done worldwide distributed databases, it's really light for what it does.

From SQLite's docs:

SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine.

Core Data is a wrapper around that, though data need not be stored in SQLite (it can also be stored in JSON, as an example).

   

Hacking with Swift is sponsored by RevenueCat

SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.

Learn more

Sponsor Hacking with Swift and reach the world's largest Swift community!

Reply to this topic…

You need to create an account or log in to reply.

All interactions here are governed by our code of conduct.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.