Moving from MongoDB to MySQL. I never understood why people felt they need MongoDB/NoSQL for their projects. Does anyone have an example where it was really necessary/advantageous?
I'll give you an example for CouchDB that, for the first time in my life, I saw an advantage:
I created a webapp where a user can author a form (with several different kinds of fields), then it syncs with a mobile app that downloads the forms and allows for data collecting.CouchDB supports synchronizing with a server very easily and already has mobile support to. If/when the user changes the number of fields in the webapp, starting to collect that data makes it very trivial... no need to schema 'alter' statements in the server and synced back to the sqlite db in the phone. It all runs couch and it "just works".
Mind you, I am very skeptical about NoSQL in general, but for this particular example, for the first time in my life, I saw a clear advantage.
- when JSON is the native language of your application, certain NoSQL implementations are beneficial. The value/need for this is changing with more RDBMS introductions of JSON datatypes.
- speed/ease of development/familiarity - sqlite is easy to set up and maintain for small installations/projects, so is mongo or couch or redis - fairly straightforward tradeoff
- leveraging other platforms. Quick example might be wanting to take advantage of Amazon Dynamo or SimpleDB. Sure, RDS is right there too and scales in a similar elastic fashion, but Dynamo especially feels much, MUCH more hands off in terms of redundancy and application design. We use Dynamo since day 1 of its release (we transitioned from mongoDB to Dynamo with 1 day of work) and have not looked back. In our particular project I cannot conceive of how or why we would want to use an RDBMS, it does not fit the task.
I'm not advocating for NoSQL over RDBMS in any given, or especially all, situations. But there are plenty of reasons to select nosql-based implementations.
According to the README they say preformance improvements with Mongo. The downside was having to port all the new features over to it.
Personally I have used it to speed up development. It allows very fast iterations early on and integrates much more nicely with most languages then a SQL based solution. Also its a lot faster the MySQL.
10gen sponsors development of a Drupal module, EntityFieldQuery[1], which aims to improve support for non-SQL databases. Although I'm unfamiliar with Drupal project layouts, I didn't find a reference to the module in the GitHub project, so I don't believe they were using it. That said, there are still challenges to making MongoDB play nicely with Drupal 7, but 10gen is aiming for better integration in version 8 (through the same sponsorship).
edit: Data stored in Drupal is way normalized, and read from a hell of a lot more than it's written to. I think in this case, when they weren't using it for general field storage, but just petitions and signatures which consist of endless names and links to user pages, the data was naturally denormalized enough. Nothing in that usecase would take more than three, maybe four joins. All it's doing in that case is just making upgrades difficult.
Session data. NoSQL isn't meant to be a catch-all solution, and it's certainly not meant to be the only database you use in a complex project. It's meant for data that you really wouldn't mind losing that you have to access a lot. Normally, that's temporary data in an app that might require it on every page view— recently viewed items, sessions, shopping carts that aren't saved for later, etc.
I can see the benefits of using something like NoSQL for temporary datastores (in memory only), but MySQL can function just fine as a key->value store as well to the best of my understanding.
I created a webapp where a user can author a form (with several different kinds of fields), then it syncs with a mobile app that downloads the forms and allows for data collecting.CouchDB supports synchronizing with a server very easily and already has mobile support to. If/when the user changes the number of fields in the webapp, starting to collect that data makes it very trivial... no need to schema 'alter' statements in the server and synced back to the sqlite db in the phone. It all runs couch and it "just works".
Mind you, I am very skeptical about NoSQL in general, but for this particular example, for the first time in my life, I saw a clear advantage.