I have given three chances to mongodb. Not fill my expectations, in the end for me there will be a need for a join or complex queries. I have tried to use it in 4 projects and does not convince me. Can anyone give me a reason other than replication to use it
What language are you writing your project(s) in?<p>If you are using Node you should use Mongoose and then you may see why some people love Mongo. Complex queries and joins (not technically called joins I guess) are incredibly easy to accomplish with that module[1]. Personally, I have migrated back to MySQL since I was unable to convince my colleagues that Mongo would last long-term and frankly I am not 100% confident either for the kind of business applications that we need[2].<p>[1]: <a href="http://mongoosejs.com/docs/populate.html" rel="nofollow">http://mongoosejs.com/docs/populate.html</a><p>[2]: payment processing industry handling billions of records
I've found it useful in storing and querying JSON documents. Basically, scraping an API (for me it was an OpenTripPlanner instance I had set up) and then being able to query any property in the data very easily.<p>But I didn't use joins, nor was this anywhere near a production server. From my understanding, if you have a heavy requirement for joins then you just shouldn't be using MongoDB in the first place. It isn't a traditional relational database.
Our enterprise on-premise software package runs on Mongo, before it used to run on relational dbmses. Here's why we changed:<p>- flexible document schema reduces migration complexity greatly, really important when we have our software deployed on many customers sites.
- flexible schema is also important to our product because we support custom forms and fields.
- the ability to store and search nested data
- replication is easy to setup
- easy to maintain, good export formats
- no dependence on customer's DBAs
- no more frustrating explain-plan debugging of underperformant joins
- text search (simple yet useful)
- regex support
- fast, up to 3x faster than SQL based engines for our use cases.
- works well as a cache
- decent also as a work queue with tailable capped collections.<p>Our biggest complain: the lack of transactions combined with data denormalization pitfalls is a PITA to work around in code.<p>Overall just a great db for when you need a flexible schema.
I just use Mongo as a big JSON / BSON storage locker for node/express stuff I'm learning. The apps all involve DOM manipulation and using HTML client API's where div id's and their positional data are stored as JSON/BSON in Mongo ( then looped through and pulled back out when the user wants them ). Mongo seem really convenient for this kind of thing. I've done one similar project with PHP/MYSQL before and the workflow seemed a bit more 'heavy' compared to Mongo whichs thus far feels a bit more in alignment with this work style( I'm also using node/express which is a bit complimentary ). So I guess my comment is more validation that its good for making small toys. Ha!
I would think it's useful for any kind of data where it's "write once, then read only" and there's a standard sequence (key) you'll use for almost every query. A blog, for example, or a twitter-type feed. In those cases, you're not doing complicated interactions with the data, just "SELECT" everything in order and display it. In those kinds of applications, consistency and atomicity doesn't matter much, and a NoSQL database might give you lower latency.
You should use the DB you need. Sometimes SQL is best, sometimes nosql.
For me, the prime reason to use mongo is if I have data that I cannot structure before hand.