Ask HN: Why use MongoDB? | Hacker News Reader

Ask HN: Why use MongoDB?

17 pointsvictormx16 comments

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

View on HN

What language are you writing your project(s) in?

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].

[1]: http://mongoosejs.com/docs/populate.html

[2]: payment processing industry handling billions of records

I used java, node and .net, this question it's because i love mongodb,I like mongodb and many of its features but I have not found a use for my projects and so far I'm only seeing mongodb for small projects or simple queries. I have not used mongoose because i do not like ORM, but I'll do some testing on it

I would strongly recommend it.

My experience with ORMs has not been pleasant either but Mongoose was very, very nice.

What would be your plan for ensuring referential integrity when working with MongoDB?

For me the ORM provided some comfort here but this is one of the concerns that caused me to revert to MySQL.

Essentially you end up with an a lot of linking by item IDs as you would with a traditional relational database but the "eventual consistency" was where I thought there may be issues in the future.

I personally never saw problems stemming from this but my projects using MongoDB never really even hit a million objects in a single collection (not 100% sure on that). Again, at scale is where I'd lose confidence.

This is entirely speculation but when it comes to critical infrastructure I can't leave anything to chance.

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.

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.

I have come to the same conclusions, for that reason I asked this question, one of the reasons that i like mongodb is that data is in JSON

Postgres is getting there, with JSON columns. You can do hstore if you like key-value, or mix it with plain old SQL tables. This combination works well for me.

I use Postgres HSTORE via Flask-SQLAlchemy. As far as my code knows, it's dict() all the way down.

And if I want to attach non-kv data like last_updated, or have foreign key relationships between one dict() and some other stuff like the corresponding user record's primary key - it's already in an RDB.

Yeah, 9/10 of the reason people use NoSQL is because it acts like an ObjectDB for JS. MariaDB does has this now as well: COLUMN_JSON(dyncol_blob);

https://mariadb.com/kb/en/column_json/

Our enterprise on-premise software package runs on Mongo, before it used to run on relational dbmses. Here's why we changed:

- 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.

Our biggest complain: the lack of transactions combined with data denormalization pitfalls is a PITA to work around in code.

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.

I'd also argue that being able to be more adaptive with how data is structured can be good for a project where things change very quickly. If you have something where the data model is of simple to moderate complexity and persistence is required, the smaller overhead of changing things on mongo vs having to update a SQL schema can be worthwhile. (For reference my specific use case was using rails with activerecord vs mongoid here).

Same here one of the reason i like mongodb and other NoSQL it's the schemaless approach

Reply on news.ycombinator.com