CODEWITHSUNDEEP
iphoneiossqlitecore-datafmdb
Cameron
Cameron

Reputation: 4211

CoreData or SQLite for iOS aggregation

I have an iPhone app that requires local storage.

My initial thought was to use core data, which is fine for a most of the app, however a major chunk is using aggregations on the data. In SQLite this is the standard use of MIN, MAX, AVG, GROUP_BY etc.

But core data doesn't implement these very well, as it is primarily for object graph management. Would it matter if I did the calculations in Obj-C once loaded from CoreData, or should I stick with SQLite and forgo the usefulness of the CoreData system other parts?

The collections for aggregation over are not huge (max 100 objects say). I need to do things like distributions.

I know there is no concrete answer here, just would like some second options. Thanks

Upvotes: 3

Views: 393

Answers (3)

BP.
BP.

Reputation: 10083

I use both Core Data and FMDB (an Objective-C wrapper around SQLite) in my app, and it works fine. Core Data adds a "Z" in front of your table and field names, so for example, if you have a Core Data entity called Contacts, you can do a query such as SELECT COUNT(*) FROM ZCONTACTS and it will give you back the results of the SQL query.

Upvotes: 1

Ulrich von Poblotzki
Ulrich von Poblotzki

Reputation: 456

You could use both. First aggregate your data, select the id and use 

NSManagedObjectContext context; // Get it some how
NSManagedObject *obj = [context objectWithID:objectID];

to get the corresponding managed object.

Upvotes: 0

V1ru8
V1ru8

Reputation: 6147

Personally I'd stay with CoreData as long as 'most of the app' doesn't use MIN, MAX, AVG... because then still 'most of the app' is still a lot then with SQLite.

Upvotes: 0

Related Questions