1

So I'm new to Core Data, everything I read says to use it - if you use SQLite you're an evil bad person. But I'm lost on some simple things. I have a bunch of data that will be used to setup a NSCollectionView, this would be relatively simple in SQLite, but I don't want to be an evil bad person. Is there a simple tutorial someplace that I'm missing? I would love to see a example SQL database based app and the same thing with core data.

  • Something like here is a table structure in SQL, here is the equivalent in core data...
  • Here is a INSERT script in SQL, here is the equivalent in core data...
  • Here is a SELECT with a JOIN and a few WHERE statements, here is the equivalent in core data...

Its even the little things that I don't understand.

  • How do I provide a pre-populated core data system
  • Where do the core data files live? in the bundle like my SQLite database would?
  • With an update to the app what do I have to do to update the core data files if they live outside my bundle?
Justin808
  • 20,859
  • 46
  • 160
  • 265
  • 2
    Regarding the "evil bad person" bit, this means that if you want to use SQLite directly, don't try to use CoreData as a frontend to SQLite. The fact that SQLite is used internally in CoreData is an implementation detail, and trying to interact with it directly can produce unintended consequences. (I used to work on a large Cocoa app that used CoreData for storage.) – bneely Feb 12 '12 at 23:00
  • 1
    @bneely - I'm reading that I shouldn't use SQLite at all, even without core data, I should only use core data in new applications. On the other hand I'm reading I should use a SQL script to pre-populate the backend core data database as you can run it in a script build phase to pre-populate the core data backend. So I'm all kinds of confused. I would rather no use SQL at all, but I'm lost on how to do even the littles things in core data. – Justin808 Feb 12 '12 at 23:12
  • You can pre populate the data programatically. This also allows you to switch the underlying data store without it affecting your application. Here is a good tutorial: http://www.raywenderlich.com/934/core-data-tutorial-getting-started – Soliah Feb 13 '12 at 00:20
  • 1
    There's absolutely nothing wrong with using SQLite directly, if it suits your purposes. Here's a real world example: http://inessential.com/2010/02/26/on_switching_away_from_core_data Personally, I found Core Data easier to understand when I stopped thinking about databases, and started thinking about objects I needed to persist in my application. I know that sounds unhelpful, but I don't even think about what the underlying DB might look like when I use Core Data (well, maybe a bit). – paulbailey Feb 13 '12 at 10:27

1 Answers1

0

Justin808,

No one is an "evil bad person" for not using CD. If you prefer to use SQLite, go for it. It is used by many applications. It is a framework. If SQLite is a technology you are used to, then use SQLite. That said, CD is the Apple encouraged path for building rich, persistent model apps on their platforms. They don't provide many tools for the pure SQL community but provide a very rich set of tools for CD apps. I've attempted to answer the technology question here: Core Data VS Sqlite or FMDB…?

About your request for a line by line comparison between the same app implemented both ways, this sounds like an excellent learning opportunity for you to write one. (I teach beginning iOS programming. The app you're asking for can be quite simple. You can probably write both versions in one weekend. I would be happy to review your work and critique your blog post describing the differences. You could make an excellent contribution to other folks in your situation trying to choose between these two technologies.)

Your questions:

Something like here is a table structure in SQL, here is the equivalent in core data...

Schemas are described differently but are substantially similar. That said, an SQL schema may not be tuned for use by CD and/or UI application or vice versa.

Here is a INSERT script in SQL, here is the equivalent in core data...

There are plenty of examples by Apple and others that tell you how to insert new entities. What is it you don't understand?

Here is a SELECT with a JOIN and a few WHERE statements, here is the equivalent in core data...

The predicate language in CD is different than SQL. As such, you will query things differently. In particular, CD is an almost "pure" set theoretic approach to organizing data. You use fetches to seed your "query" and set operation to refine it. Beyond that, I need to direct you to one of the many books about CD and its predicate language.

How do I provide a pre-populated core data system

CD depends upon a file like every other DB system. You provide it in your bundle and copy it into your documents directory (on iOS) when you need to mutate it.

Where do the core data files live? in the bundle like my SQLite database would?

Yes, they do. If you are using CD with a SQLite backing store, then it is just a SQLite DB file. (There is a special issue if you allow CD to store large BLOBs in the file system.)

With an update to the app what do I have to do to update the core data files if they live outside my bundle?

I'm not sure what you are asking here? If you update your schema between versions, just as with SQLite, you will need to migrate your database to the new schema. CD provides some tools that work very well for additive migrations.

Good luck with your choice.

Andrew

Community
  • 1
  • 1
adonoho
  • 4,339
  • 1
  • 18
  • 22