41–50 of 122 posts
Earlier quoted context omitted.
MongoDB has THE WORST vendor lock-in imaginable, so only use it if you know that you could throw everything away. Source: my last employer used MongoDB, and switching to an RDBMS would have forced us to rewrite ~80% of the codebase.
About 80% rewrite: it is poor abstraction problem rather then vendor lock-in one
Not even a hackathon?
They've sponsored tons of hackathons, so it's super popular there. But to me, a big part of hackathons is learning something new, and MongoDB is apparently just not worth learning.
Evidence for those claims that MongoDB is "fast" never materialized, nobody really knew where the claim came from, yet it was constantly repeated. They sponsor a lot of hackathons, and so on.
Relationships in MongoDB are commonly stored as ObjectID references, and (at least on node) the default Mongo client (Mongoose) makes you write schemas to enforce these. I think Mongo is awful too, and I'm sure there are problems with this approach - I'd love for someone with more DB knowledge to go into details - but saying there are 'no relations' seems to be an oversimplification.
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.
Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.
Earlier quoted context omitted.
MongoDB has THE WORST vendor lock-in imaginable, so only use it if you know that you could throw everything away. Source: my last employer used MongoDB, and switching to an RDBMS would have forced us to rewrite ~80% of the codebase.
About 80% rewrite: it is poor abstraction problem rather then vendor lock-in one
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…
Relationships in MongoDB are commonly stored as ObjectID references, and (at least on node) the default Mongo client (Mongoose) makes you write schemas to enforce these. I think Mongo is awful too, and I'm sure there are problems with this approach - I'd love for someone with more DB knowledge to go into details - but saying there are 'no relations' seems to be an oversimplification.
Mongoose is also very much not the default MongoDB client in Node.js - it's a third-party client library by Automattic. The official client according to the MongoDB documentation is `mongodb` (https://www.npmjs.com/package/mongodb), which does not feature relations.
I, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well. I've got nothing against relation databases but there are not a solution to every single problem. Heck, why not decide first if you can use flat files? Do you really need to query and join. Not all problems require that sort o…
1. The bugs that MongoDB historically suffers from are those that are unlikely to occur for most people, but when they do cause the most suffering. This is a combination of them being incredibly hard to replicate, but more insidiously that the system keeps working, it just has a small data corruption. This can obviously lead to huge problems down the line. The conclusion is firstly that just because you haven't seen a problem doesn't mean there isn't one, but also just because there isn't a big problem for you doesn't mean there won't be one in the future.
2. Databases have some of the most demanding testing around, due to the important requirements placed on them. There's a really good talk floating around from a guy at FoundationDB. The sorts of bugs that keep cropping up in MongoDB are the sorts of bugs that level of testing would find, which is a very bad smell. Thus, one should only resort to MongoDB if no other solution is reasonable.
But in reality, for most tasks something like Postgres (with JSON additions) or CouchDB etc is equally suitable and easy to use. This means that most new users of MongoDB can actually afford to use a better/less buggy database, they just choose not to.
3. Flat files are generally a silly idea mostly because of the additional tooling that databases give you. ORM systems make using a database much, much easier than using flat files, and the databases usually allow easy analytics. They also typically give better error messages, better performance, better extensibility etc. If it comes time to move your data into the cloud, you'll have a much easier time of it if you use a database etc. It's a win-win in almost every case.
Earlier quoted context omitted.
1. There was no such warning for a long, long time. 2. It's a dumb limitation, and an architectural issue as far as I'm concerned. 3. It still doesn't justify silently throwing away data for years. 4. Many of the points on my list remain unaddressed, and likely never will be addressed. EDIT: Additionally, the typical system administrator doesn't install MongoDB from the 'Downloads' page, but uses a package manager, a…
That 32bit startup warning has been in place since 2009. It was in the README in 2008 (IIRC, pre-1.0). https://github.com/mongodb/mongo/commit/b3322b86a014683018ac... There's plenty in Mongo to complain about, but grousing about the 32-bit limitation just makes you look like you're bad at reading introductory documentation.
This was the case until as late as 2014: https://web.archive.org/web/20140704182658/http://www.mongod...
And again, the 'download' page or README is not sufficient for such a warning, nor is a startup message a reliable place to put it (because of initscripts and such). It should have been in all the relevant places in the documentation, instead.