Was MongoDB Ever the Right Choice?

Post by aeorgnoieang » Wed, Mar 27, 2019, 8:24 PM UTC

flurdy wrote: post #99

matwood wrote: post #62

Earlier quoted context omitted.

The problem with thinking a library like Mongoose satisfies those constraints is that it only works with a single application. Every database I've worked with that made it beyond a prototype outlived the original application. So you either end up building an RDBMS app/api in front of mongo for every new application to use or you have to translate those constraints to every client. I'm of the opinion to let the "aweso…

True, using a library to hide the limitations of a DB smells bad. It is fixing the problem in the wrong location. I may have misread your comment but rarely do more than one client application access a database. Especially in today's often Microservices architecture. So using a library as mentioned is fine. And as the app evolves/gets rewritten you can keep the library or replace it with a similar one. Over 10+ years…

Post by bunderbunder » Wed, Mar 27, 2019, 8:36 PM UTC

rwmj wrote: post #43

matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

I once worked for a company where Lotus Notes fulfilled a similar role (this was back in the late 1990s). Eventually they ran an entire free to sign up web-based email system using 4 giant Notes instances. It was an absolute nightmare, but probably the company would never have happened otherwise because Notes was all that the founders knew. My job was managing the migration off to a normal SQL database, which took th…

Post by scarface74 » Wed, Mar 27, 2019, 9:02 PM UTC

aeorgnoieang wrote: post #200

scarface74 wrote: post #144

Earlier quoted context omitted.

Writing DDLs are hard when you don’t know in advanced what the schema is or the schema is changing frequently. A lot of things “become popular” but that doesn’t necessarily mean they are good.

All the SQL databases with which I'm familiar support large string columns. What's the downside to just stuffing your schema-less or volatile-schema data in one of those?

  var people = db.GetCollection().AsQueryable();

  var seniorMales = from p in people where p.Age >= 65 && p.Sex == “M” select p;

  var people = context.People;

  var seniorMales = from p in people where p.Age >= 65 && p.Sex == “M” select p;

Post by mr_toad » Wed, Mar 27, 2019, 10:58 PM UTC

felixfbecker wrote: post #89

scarface74 wrote: post #63

Earlier quoted context omitted.

I’m a big fan of Mongo for the use case you described - searching by ID and all information in one document. But people don’t seem to understand that there are plenty of scenarios where you really either don’t know the schemes in advance and/or the “schema” is defined by an external source. I worked for a company that sold software that allowed users to create forms that could be filled out either on the web or via a…

PostgreSQL's JSON columns are pretty powerful

Post by thawkins » Wed, Mar 27, 2019, 11:49 PM UTC

jandrewrogers wrote: post #128

TimFogarty wrote: post #61

Earlier quoted context omitted.

The Jepsen tests [1] have been run against MongoDB - while older versions presented edge-case opportunities for data loss, that's no longer the case with recent versions. The Jepsen tests also specifically test sharded clusters. From Aphyr's report: > MongoDB 3.6.4’s sharded clusters offer comparable safety to non-sharded deployments. These tests are now integrated into MongoDB's regular test suite. Maybe MongoDB was…

FWIW, the data loss I was referring to happened on a single node. There may have been issues in a distributed environment as well but we never got there.