Hacker News new | ask | show | jobs
by trimbo 4704 days ago
> very appealing option in a number of cases.

What cases do you have in mind?

2 comments

Mongo sucks. I've used it in production for millions of people. I would never recommend it ever again. It's convenient, about the same way a hooker is.
Maybe your app wasn't suited for what it's good as. A File system would suck as a relational database... that doesn't mean it sucks in general. I suspect you had the same problem with Mongo.
It's confusing to see responses like this.

We continually hear about how great MongoDB supposedly is from its advocates, with them claiming it's suitable as a general-purpose database.

Yet when somebody who has apparently used it in a production setting speaks out against it and its numerous flaws, the problem isn't with MongoDB. No way! It's a "problem" with the app "not being suited for" what MongoDB is "good at".

I don't thing any database/technology is well suited for everything. And never said as such.

But as a counter point... We don't know this was a 'general purpose' problem... so your point isn't even valid even if you were responding to something I said... Unfortunate.

Rapid iteration comes to mind (as a result of its lack of schemas). It's also great if your objects are JSON documents, and as such it's particularly suited for uses such as a backend to Backbone.

Those are two areas in particular where I would first look to Mongo.

Don't lie to yourself, it has schemas. They are just implicit. Want to write JavaScript migration scripts for changing the Schema? I sure don't. But that is not even the begining to describe how broken mongodb design is. getLastError as a way to do write confirmation?
You can call them whatever you want, but I don't need to write any migration scripts when I change the schema. Writing a migration script MIGHT be a good idea, depending on my setup, but I definitely don't NEED to.

I don't really know what you mean about the design being "broken", unless you mean that it's "different", in which case I would agree.

As for write confirmation, you have flexibility in that regard. You don't need to be checking getLastError for write confirmation[0], though if you wanted to use a broken pattern, you could.

[0] http://docs.mongodb.org/manual/core/write-concern/

The first reason sounds a lot like 'hacking things out.' That is wonderful in the early stages of development, but 'production' doesn't just getting the app live quickly. With an ORM, let's take Rails as an example, migrations make schema changes extremely fast.

As for JSON, Postgres has first class support for JSON data field types.