23

I'm just starting to read up on NoSQL technologies such as MongoDB and CouchDB. I'm interested in knowing whether I can use MongoDB or indeed any NoSQL technology as a replacement for Core Data applications.

Core data applications can take a long time to learn and implement, especially if your app is complex and you just want to do some simple add, edits, deletes and queries (CRUD stuff).

Because it looks like JSON and looks like it can run really fast; I'm interested in the implementation of NoSQL over Core Data.

Can I run MongoDB as native? I did some Google searches but wasn't really able to get the specific answers I'm after.

Such as:

I am not sure what the remit is for NoSQL on iphone platforms, is it supported, would it be denied by the Apple team if I submit an app with NoSQL on it?

Thanks

zardon
  • 2,910
  • 6
  • 37
  • 58
  • 5
    Core Data is not a database. Theoretically one could use Core Data **with** NoSQL. – BoltClock Mar 02 '11 at 19:30
  • core data doesn't take long to learn! i find it quite easy once setup – james Mar 02 '11 at 19:32
  • 4
    mongod is a server. Correct me if I'm wrong but Apple isn't going to allow you to install mongod with your application. – Bernie Hackett Mar 02 '11 at 20:08
  • 1
    Your question is pertinent. There are times you will rather use a different Data format/storage than the one provided by the platform's SDK. In that case there are embedable databases (libs or source) you can add to your project. There are drawbacks, but at least you can port your application to other OSes if the DB and the app are written in C/C++. Concerning NoSQLs there are probably some solutions out there. – Coyote Jan 19 '12 at 00:55
  • Why not use the REST interface on MongoDB and make REST calls via NSURLRequest. –  Aug 30 '12 at 21:55
  • Couchbase Mobile rather would be the consideration here for a replacement of Core Data – sweetiewill Jan 21 '16 at 22:58

8 Answers8

22

As an aside, I will note that it's a common misperception but Core Data is not a database system.

Instead, it is a runtime object graph management system with persistent tacked on as option if you want it. It's primary function is to provide the model layer of the Model-View-Controller design pattern. As such, it deals with a lot more than just getting data on and off a disk.

Core Data does have a learning curve but in my experience the biggest obstacle many face is trying to treat Core Data as some kind of object oriented wrapper around SQL. From that perspective Core Data is very confusing because it seems to require to learn so much that has nothing to do with persistence.

Using database like SQLite, MongoDB and CouchDB for persistence won't really speed things along at all because, although you might better understand how they get data on and off the disk, they won't help at all in managing the data and the relationship to the other data objects and the objects of the UI. You still have to have a data model and you will have to code all that up by hand. Unless your data model is extremely simple, that will take more time than learning Core Data.

The best way to learn Core Data is to ignore the fact that the object graph can be persisted at all. Just start from the perspective that you've got a lot of objects that represent the data model of you app and you have to manage their attributes and relationships.

Ramiro González Maciel
  • 695
  • 7
  • 12
TechZen
  • 64,370
  • 15
  • 118
  • 145
  • 2
    I believe Core Data + DB (SQLlite) = NoSQL!! – Mohammad Abdurraafay Mar 10 '11 at 12:50
  • 2
    No, not really. NoSQL is about structured ***storage***. Storage is an afterthought in Core Data. See this related answer about when to Use Core Data http://stackoverflow.com/questions/5237943/creating-a-json-store-for-iphone/5249674#5249674 – TechZen Mar 10 '11 at 15:37
  • The larger and more complex the data, the better a solution Core Data is. – TechZen Mar 10 '11 at 15:40
  • Great way to look at it @TechZen – Chris Wagner Oct 10 '12 at 02:09
  • I'm sorry, but I disagree. Document DB's exist precisely to solve this problem - directly storing complex graphs WITHOUT having to to any management. You simply make your objects any way that makes sense to you, and save them. And if this objects change, just change them, it will have no effect on the store. CD is a nightmare when it combines persistence AND changes. – Maury Markowitz Apr 14 '15 at 13:54
  • @MauryMarkowitz - Possibly, but how about other features like migration of models and data, parallelism, cloud syncing, long term backing from an Apple equivalent etc? I don't think anything really combines all the features top to bottom available through Core Data. But that feature set is the cause of the steep learning curve. Core Data is a huge API because it does so much. I have not found anything that can actually replace it completely especially in terms of being able to upgrade and scale. Neither can any other technology assure it will always be supported going forward. – TechZen Apr 14 '15 at 20:13
  • @MauryMarkowitz - 1) e.g. Realm (Realm.io) show promise. It's easier to learn, get running, cross platform vis iOs and Android but still does not have near the feature set of Core Data. e.g. its mobile only so if you want a Mac/PC to mobile app, it can't help. Most alternatives I have checked have about 80%-90% of what I need for any given project, usually some really strong benefit, then a deal breaker. Even if I found one good fit for one project, I would still have learn a new API. 2) My main point originally was to not think of CD as an SQL wrapper. That still holds. – TechZen Apr 14 '15 at 20:30
  • 1) Having said all that, I'm pretty nose down in the Apple ecosystem so no one should take my answer about alternatives as anyway definitive. Its so easy for me to work in CD I don't devote a lot of energy to alternative research. 2) In any case, for the small independent developer, the iron law is always pick the tech that will allow you ship, if don't ship nothing else matters. If learning CD is going to so bog development you can't ship and/or you already know another API use it in most cases. You have to ship before you can worry about upgrading features or scaling. – TechZen Apr 14 '15 at 20:35
  • In 2021 Crud is literally 2 lines in core data. There isn’t another solution out there that can do that. Yes it takes time to change your brain to think in core data but it’s the fastest way to get a data based application up and running. – ngb Sep 16 '21 at 11:12
4

MongoDB is probably not a good fit here. The server assumes that disk space is not a limiting factor. The current stabel brance (1.6.x) does not provide data durability on a single instance. It also uses memory mapped files which are fine on dedicated servers but will cause lots of disk churn and unnecessary memory use on a typical PC. I have no experience with Core Data, but it sounds like a septate niche to me.

John F. Miller
  • 26,961
  • 10
  • 71
  • 121
3

MongoDB is not designed to be used as an embedded database. It is designed for speed and scalability and unlikely fits the architecture of an embedded OS like IOS. However talking to some MongoDB-backed service in the "cloud" through standard protocols like HTTP/S should not be an issue. You just need to write some web-gateway in front of MongoDB.

2

I know that this is a really old question, but I thought I would offer an answer anyway. Couchbase has a suite of software called SyncPoint, which includes TouchDB, which is a build of CouchDB built to run on iOS natively and synchronize itself with any Internet accessible CouchDB instance.

Travis James
  • 19
  • 1
1

CouchDBX http://www.couchone.com/get is a Cocoa application that bundles CouchDB into an OSX app if that is what you are looking for

macarthy
  • 3,074
  • 2
  • 23
  • 24
1

MongoDB Mobile is an smaller version of the MongoDB database, optimized to run on mobile and IoT devices.

MongoDB Mobile comprises two core pieces:

A mobile-optimized version of the MongoDB database that runs locally on the device, enabling offline access to data. Native Java (Android) and Swift (iOS) SDKs that manage the lower-level database operations and provide methods to interact with MongoDB Mobile and the Stitch backend.

https://docs.mongodb.com/stitch/mongodb/mobile/mobile-features/

Venu Gopal Tewari
  • 5,672
  • 42
  • 41
0

Good question. Core Data is tied to schemas and migrations so it's pointless to use it with a NoSQL database.

I haven't tried any of these yet, but there are some claimed solutions out there:

Definitely check those out.

Simon Woodside
  • 7,175
  • 5
  • 50
  • 66
  • Couchbase Mobile is very much alive and being used in mission critical use-cases. Can see this article for reference: http://www.couchbase.com/nosql-resources/presentations/how-ryanair-reduced-booking-time-from-5-to-less-than-2-minutes.html – sweetiewill Jan 21 '16 at 22:59
0

For this, I recommend ObjCMongoDB. Is a library for MongoDB and BSON:

https://github.com/paulmelnikow/ObjCMongoDB

Features

  • Simple BSON encoding and decoding, using dictionaries.

  • Built-in support for arrays, dictionaries, embedded objects, strings, numbers, dates, object IDs, and the miscellaneous MongoDB types.

  • More complex encoding and decoding based on NSCoder's keyed coding scheme. A robust delegate interface lets you implement encoding and decoding entirely outside the model classes if necessary.

  • Automatically encodes and decodes Core Data entities. Using the coder's delegate interface you can customize the default behavior, or simply implement alternate behavior it in the entity class.

  • Aims to feel Cocoa-like, not Mongo-like. For example, method names in MongoKeyedPredicate and MongoUpdateRequest are natural in Cocoa, though they don't conform to the underlying Mongo keywords.

Ricardo
  • 2,086
  • 25
  • 35