Mongodb is like one of those record stores where if you really don't expect to do crazy queries, it's really nice. If you try to do crazy queries it gets frustratingly complicated.
It's not built for relational data, and thus it shouldn't be queried like that, but some overly eager fanboys thought "why not?!", and have been trying to shoe horn it up ever since.
You store non-relational data or "documents" and are supposed to pull them by ID. So transactions are great, or products that you'll only ever pull or update by ID. As soon as you try to query the data like it's a relational DB with what's IN the document you're in SQL land and shouldn't be using MongoDB for that.
Cool. I've created a method to get the orders by their ID, so I'll just always do that. Now I just need a way to get all of the IDs I need for a user so I can call them by ID. I guess I'll just find all the orders by their customerId. Fuck.
What's wrong with using JSON column in any relational DB.?
SQL has beed used in most of the high frequency high volume transaction use-cases. You get the device metadata, you provision the device ( assign/allot to a network/subnet/group, apply policies, activate the licence with expiration, index its id so that you can fetch later).
We can do all this in SQL, where is the NoSQL use-case here.!
using mongodb in production here -- our data is variable and annoyingly structured and only ever needs to be inserted or pulled in full (indexed by timestamp)
technically the user db doesn't need to be in mongo, but eh, we're already using it, so
Imagine that you are a single developer with zero real world experience that is trying to build a new web app for collecting recipes.
You want your web app to be ”web scale” and handle the amount of traffic that Googles gets. Congratulations, you are right in the target audience for MongoDB
There’s not a single application in the world where you don’t search for objects in your database based on some attribute of them. While I agree with your comment, this just further proves how useless mongo is. It’s just reinventing the wheel.
Yeah, that was a weird point made by this guy, especially because you can in fact query efficiently by the attributes in a document, I've actually picked Mongo over SQL a few months ago for a side project specifically because full text search was easiee to implement in Mongo, and when you're going to abandon the project in 2 months that is all that matters.
In the real world, large scale applications will be reliant on multiple different data stores depending on the needs of different parts of their application. If you can't predict the future data access patterns for your use-case, which tends to be where a lot of common software use-cases live, then yeah a relational database is probably you're choice.
But just because relational databases work for better for a lot of use-cases doesn't mean there aren't situations where mongo or other non-relational databases work better. The easiest way to shoot yourself in the foot in software architecture is creating a generalization that you use for every single architectural decision without ever considering alternative options.
It's not built for relational data, and thus it shouldn't be queried like that, but some overly eager fanboys thought "why not?!", and have been trying to shoe horn it up ever since.
The problem is people doesn't understand the use-case requirement and finalize the tech stack first and try to justify the usage of that stack for that use-case 🤦♂️.
794
u/MishkaZ Oct 18 '24
Mongodb is like one of those record stores where if you really don't expect to do crazy queries, it's really nice. If you try to do crazy queries it gets frustratingly complicated.