Which are the most noteable things which make working with Core Data different than with MySQL?

views:

answers:

+1 Q:

Which are the most noteable things which make working with Core Data different than with MySQL?

One thing I have in mind is, that datasets in Core Data (or lets say: managed objects) have no ID like known from other databases such as MySQL. Also, they're not in a specific guaranteed order.

What else makes Core Data much more "special" compared to working with a relational database like MySQL? Besides the whole object graph persisting and ORM stuff?

+2 A:

This is a good article explaining the main differences. The biggy for me is

'Core Data cannot operate on data without loading the data into memory'

This alone makes core-data and MySQL suited to totally different tasks.

mustISignUp 2010-06-02 16:23:25

How can MySQL operate on data without loading it into memory? You don't have to bring the whole data store into memory in either case but you have to bring it into memory to operate don't you?

Ukko 2010-06-02 16:29:33

Not really, no. If your MySql database is on disk and you want to update a value you can do it directly. In core data if you want to update, say, a 'date' attribute of an 'appointment' you must fetch the appointment, modify the date, then commit the updated appointment back to the managedObjectContext.

mustISignUp 2010-06-02 17:03:16

Please Note: I'm not in anyway saying that one is better than the other - just that they should not really be thought of as interchangeable. Core-Data is not an ORM, it works just as well without a database at all.

mustISignUp 2010-06-02 17:14:40

@mustISignUp: I don't want to get too hair splitting, but wouldn't you have to pull in the table row you were going to modify at some point in the process. How is that different from faulting in a single object to modify it? If you are using the SQLight backend they might even be exactly the same operation, modifying a single database row.

Ukko 2010-06-02 18:52:30

@mustISignUp: As to the ORM issue I think we might be talking to cross purposes, in what way can Core Data operate without a database? When using the XML backing store? In that case the XML is just as much a database as a SQLight backend. It just happens to have different performance characteristics.

Ukko 2010-06-02 18:56:31

Yes when using the xml store - or- the in memory store. The 'flavour' of backing store is irrelevant to core-data, as, unlike say with Active Record, you cannot use an arbitrary schema for that backend, and you can't use other tools to access that backend. If you use a SQLight light backend you cannot use arbitrary SQL queries on it as you can make no assumptions about how Core-Data uses it. And no, to modify a field in a mysql database you would not HAVE TO pull the row, let alone then have to commit the row back to the database.

mustISignUp 2010-06-02 20:06:40

+1 A:

The big difference I would say is that Core Data is built on an ORM, an Object Relational Mapping, while MySQL is just a relational database. You could actually host CoreData on MySQL if Apple wanted to let you. Instead they use a different embedded SQLight solution or an XML representation depending on what you want for your backing store.

Ukko 2010-06-02 16:31:30

ansaurus

tags:

views:

answers:

Which are the most noteable things which make working with Core Data different than with MySQL?

related questions