I know this is a big question and it's not a yes or no answer but we develop web apps and are looking into using MongoDB for our persistence solution. Combining MongoDB with NoRM for object storage.
What I want to ask is what pitfalls have you experienced with switching from SQL to mongo? When is mongo simply not the right solution and is mongodb's advantages enough to move development from SQL?
Many thanks in advance for any advice you may have.
I've been poking around with it a few days now. This is what I can say about it:
FOR:
AGAINST:
One thing i noticed that's missing from the tutorials: Initialise your lists inside your object otherwise it will throw an error while trying to .save(yourobj). The safest thing to do is write a constructor in your class that makes sure you don't have any NULL objects inside your object. This way you won't get an error if you forget something.
You might find a couple of pros and cons of using a NoSQL database (MongoDB included) in this Getting started with NoSQL. A quick summary would be: a different data model (think if a mapping from the object model to "this new model" is needed, will it work well), a different query model (MongoDB queries are pretty capable though when compared with others), no transactions (you have some atomic operations though).
Anyways, from my perspective the most important change is the data model and the way you are designing your app with this new approach.
In my opinion the format of your data should be the primary concern when choosing a storage backend. Do you have data that is relational in nature? If so, can it and is it a good idea to model the data in documents? Data modeling is as important in a document database as in an relational database, it just done differently. How many types of objects do you have and how are they related? Can DBrefs in Mongodb do the trick or will you miss foreign keys so much it will be painful? What are your access patterns for the data? Are you just fetching data of one type filtered by a field value, or do you have intricate fetching modes?
Do you need ACID transactional integrity? Does the domain enforce a lot of constraints on the data? Do you need the scalability factor of a document database or is that just a "cool" thing to have?
What are your consistency and data integrity requirements? Some NoSQL solutions and MongoDB in particular are quite loose on the write consistency in order to get performance. NoSQL is no uniform landscape and other products, e.g. CouchDB has other characteristics in this department. Some are tunable too.
These are all questions that should go into the choice of storage.
Some Experiences
cons
pros