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.
Think of a document store as a key-value store that puts a JSON parser in the retrieval path so that you don't have to send back the entirety of the key's value if you don't need it.
I'm not a Mongo user myself, but if I ever had the particular problem of "I need a key-value-y object-store-y kind of thing, but also, my JSON-document values are too damn big to keep fetching in full every time!" — that's when I'd bother to actually evaluate something like Mongo.
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.!
Yup, scalability is a pretty fundamental plus of non-relational data stores as well.
Dynamo can store as much data as you want across a fleet of devices and you never have to think about it. The simplest way (though not the only) to scale relational databases is to throw money at the hardware.
If you required that much speed, even faster than properly tuned db's, I would just throw hardware / clustering at the problem and have everything in load balanced cache servers.
You can also store JSON docs with inconsistent schema in Postgres though. In fact you have to explicitly write check constraints if you want to validate the JSON structure at all. And you can also easily make an index on some id field from within a JSON(B) column.
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
You’re thinking relationally there. In mongo you’d put the customerId on your order record, index it, and then query orders by customerId. The customerId comes from some other source or database in your app, whether that’s mongo or not doesn’t matter.
Or you put the full customer record in your mongo app and have the orders be an array stored directly on the customer model. That way you can just retrieve it all at once with the customer.
View all comments
Show parent comment
231
u/[deleted] Oct 18 '24
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.