Live data from Hacker News

Never, ever, ever use MongoDB

cryto.net

61–70 of 122 posts

Re: Never, ever, ever use MongoDB

#61
post #60

Earlier quoted context omitted.

The article mentions CouchDB and other schematic-less, document DBS, which should be equally good for prototyping but suck less.

I don't understand why a schemaless database is so great for prototyping. Most of the pain from schema changes is when you have a lot of code or a lot of users depending on an existing schema, so it's hard to change (or at least, hard to change while maintaining uptime). Running ALTER TABLE on a small dataset with almost no users is trivial.

It might be trivial but it's another thing to do, which is is simply not there otherwise.

Re: Never, ever, ever use MongoDB

#62
post #36

I've used MongoDB recently for the first time, for an internal project. Being schemaless, I believe it did speed up development time significantly, and allowed me to add stuff more gradually, but you could say that's just a way to indulge a certain laziness of design. Now that the project has matured, stepping back I can see how a relational database would be a better fit, but if I had used a rdbms from the beginning…

> but if I had used a rdbms from the beginning I might have not "shipped" quite as quickly.

I doubt that. As mentioned in the article, migrations with rollbacks basically solve this problem, and let you iterate through schemas quickly.

> Swapping it out for a real rdbms will mean changing a couple of classes anyway, nothing dramatic.

In theory, perhaps, but I have yet to see that in practice. I do freelance code review and tutoring for a living, and in every case I've seen, a significant amount of work would be needed to move to a different database.

Re: Never, ever, ever use MongoDB

#63
post #4

How would one use Meteor.js without MongoDB though? Are you saying not to use Meteor.js too? I was thinking about maybe toying with the idea of making a fully reactive RethinkDB package for Meteor.js.

There is a wrapper for Postgre: https://github.com/austinrivas/meteor-postgresql

Re: Never, ever, ever use MongoDB

#65
post #10
post #5

Earlier quoted context omitted.

I doubt ElasticSearch is easier to set up and get started with than MongoDB, especially if you're coming from limited knowledge about either.

Use Redis, then.

Actually Redis is as safe as PostgreSQL. Read the documentation please :)

Re: Never, ever, ever use MongoDB

#66

Now with PostgreSQL 9.4 there isn't really any reason to use MongoDB (JSONB is better suited than BSON). For any other use CouchDB.

sadly, meteor uses mongo and only mongo.

And we are using meteor (which is based on node)

Two levels: node and mongo == two levels of sadness.

(let the flames commence)

Re: Never, ever, ever use MongoDB

#67
post #4

How would one use Meteor.js without MongoDB though? Are you saying not to use Meteor.js too? I was thinking about maybe toying with the idea of making a fully reactive RethinkDB package for Meteor.js.

There is a wrapper for Postgre: https://github.com/austinrivas/meteor-postgresql

yeap... but you have to give up many of the reasons for using meteor. (the dynamic refresh, etc.)

The package is really just a simple wrapper around an npm library.

Because meteor is node-based any db that node has libraries for can be "used" .... at the expense of giving up on most meteor features.

Re: Never, ever, ever use MongoDB

#68

Earlier quoted context omitted.

There are a few. Mongo has excellent integration with Hadoop and is becoming very popular in the big data analytics space. Likewise it is gaining traction in the EDW space as a result of their partnerships. Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.

> Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes. It's not hard to make it easy to do a thing in the wrong way - and that's exactly what MongoDB does. It doesn't make you set up authentication or table schemas, so it looks 'really easy to set up'. In reality, though, you're wasting hours to save 10 minutes. Because at a later point, you're going to have…

I'm all for using tools that don't make bad things easy, but I think threeseed is saying that for hacks and spikes, the "later point" you're referring to might not matter. (I agree that those are the only jobs I'd use Mongo for, too.)

Of course, if you're at a company where those spikes find a way of turning into production code, then it's a different story.

Re: Never, ever, ever use MongoDB

#69
post #67

Earlier quoted context omitted.

There is a wrapper for Postgre: https://github.com/austinrivas/meteor-postgresql

yeap... but you have to give up many of the reasons for using meteor. (the dynamic refresh, etc.) The package is really just a simple wrapper around an npm library. Because meteor is node-based any db that node has libraries for can be "used" .... at the expense of giving up on most meteor features.

IFRC, postres can notify clients of changes, so you should be able to implement the missing features - that is to say the limitations are artificial at this point
Post reply on HN