Hi Jonathan! Thanks for posting! I am also currently learning NoSQL. (Though I'm working with Firestore and not MongoDB.) Out of curiosity, what specifically is not clicking with you and confusing? Though I'm just too beginning, maybe we can compare notes? Historically, I've worked quite a bit with relational databases before and coming from that world, NoSQL is definitely a new paradigm!
From what I've gathered so far though, the general thrust of NoSQL (at least from all of the great Firestore tutorial videos I've watched) is that it asks you think about the "access pattern" of your data from your "average user" standpoint. What does most of your users do most of the time? When you work with relational databases, for example, it's common to normalize data. The most canonical example being having your standard "Users" table and then referencing users in another table (say, "Reviews" if you're making a restaurant review site) by "User Id".
The upside to this: Say your User changes his/her name. No problem! All the reviews that reference that UserId will also immediately reflect that name change.
But in NoSQL world, the motivating question --at least as I understand it so far-- is that, seriously: How often does a user change his/her name?
And so the idea of NoSQL is to denormalize data in many places where it makes sense. Meaning, we literally include the user's name in every single review. Most of the time, especially with these kind of sites, you're going to be reading the data a bajillion times more than you'll be updating it. And so the beauty of NoSQL is that instead of getting that additional data with a join on every single read call, why not just read once and get all of the data immediately?
(The downside, btw: of course if a user does change his/her name, now you've gotta go through all of his/her reviews and update accordingly! Reviews would still be tied to Users by some uid, for example.)
Anyway, would love to compare notes, if you're keen! The learning never stops! đ
Thanks so much for the comment! Yeah including the user name in every single review is mind blowing to me. Especially coming from a relational model. I would totally expect a foreign key! Something that I learned the hard way at work is how easy it is to muck up the data in your NoSQL DB. For example, you could accidentally make one User completely different to another! What are your thoughts on preventing things like this? Is it up to your application code, or are there constraints you can put on your DB?
Something that I'm learning about next is indexes! Have you found any good resources explaining them?
So I haven't specifically studied indexes yet in the NoSQL world but from what I remember watching Todd Kerpelman's Firestore videos is that the "big O" of a query (at least in Firestore world) is "proportional to the number of results being retrieved and not the number of documents being queried." So whether you're fetching 10 docs from 100 or 10 docs from 1 million, it's the same. And the only way you can possibly accomplish that is with indexing. So that's really cool. Idk anything about Mongo but I'm guessing it's similar?
As to your other point-- yes, mucking up data in NoSQL is easy! As you learned the hard way, gotta be careful that you're actually getting/writing the docs and key/values you think you are!
I'm still learning myself, but in Firestore world, they offer a rudimentary ORM so when you fetch a doc from the DB, you can actually populate it as a well-defined model using something called withConverter. This is the first suggestion I'd make: Use an ORM. From many SO posts I've read, people seem to often fetch plain JSON objects from the db and then begin reading and writing with reckless abandon. That approach seems insane to me and ripe for disaster. âšī¸
The only other suggestion I have, and this is more general, but recently I just started getting into TypeScript. Idk if you're working with JavaScript, but if you are-- I honestly can't recommend TypeScript enough. Static type checking and having the IDE (VS Code, personally) work for you is an honest-to-God lifesaver. Because with raw dot notation in JS, God-forbid if you make a typo somewhere-- then you'll just inadvertently end up creating that property in your object and it becomes a huge mess in a hurry.
This is specific to Firestore, but today I actually posted an answer on SO that's related to this. Again, I haven't worked with Mongo at all but I imagine there must be a similar equivalent!
Hi Jonathan! Thanks for posting! I am also currently learning NoSQL. (Though I'm working with Firestore and not MongoDB.) Out of curiosity, what specifically is not clicking with you and confusing? Though I'm just too beginning, maybe we can compare notes? Historically, I've worked quite a bit with relational databases before and coming from that world, NoSQL is definitely a new paradigm!
From what I've gathered so far though, the general thrust of NoSQL (at least from all of the great Firestore tutorial videos I've watched) is that it asks you think about the "access pattern" of your data from your "average user" standpoint. What does most of your users do most of the time? When you work with relational databases, for example, it's common to normalize data. The most canonical example being having your standard "Users" table and then referencing users in another table (say, "Reviews" if you're making a restaurant review site) by "User Id".
The upside to this: Say your User changes his/her name. No problem! All the reviews that reference that UserId will also immediately reflect that name change.
But in NoSQL world, the motivating question --at least as I understand it so far-- is that, seriously: How often does a user change his/her name?
And so the idea of NoSQL is to denormalize data in many places where it makes sense. Meaning, we literally include the user's name in every single review. Most of the time, especially with these kind of sites, you're going to be reading the data a bajillion times more than you'll be updating it. And so the beauty of NoSQL is that instead of getting that additional data with a join on every single read call, why not just read once and get all of the data immediately?
(The downside, btw: of course if a user does change his/her name, now you've gotta go through all of his/her reviews and update accordingly! Reviews would still be tied to Users by some uid, for example.)
Anyway, would love to compare notes, if you're keen! The learning never stops! đ
Thanks so much for the comment! Yeah including the user name in every single review is mind blowing to me. Especially coming from a relational model. I would totally expect a foreign key! Something that I learned the hard way at work is how easy it is to muck up the data in your NoSQL DB. For example, you could accidentally make one User completely different to another! What are your thoughts on preventing things like this? Is it up to your application code, or are there constraints you can put on your DB?
Something that I'm learning about next is indexes! Have you found any good resources explaining them?
So I haven't specifically studied indexes yet in the NoSQL world but from what I remember watching Todd Kerpelman's Firestore videos is that the "big O" of a query (at least in Firestore world) is "proportional to the number of results being retrieved and not the number of documents being queried." So whether you're fetching 10 docs from 100 or 10 docs from 1 million, it's the same. And the only way you can possibly accomplish that is with indexing. So that's really cool. Idk anything about Mongo but I'm guessing it's similar?
As to your other point-- yes, mucking up data in NoSQL is easy! As you learned the hard way, gotta be careful that you're actually getting/writing the docs and key/values you think you are!
I'm still learning myself, but in Firestore world, they offer a rudimentary ORM so when you fetch a doc from the DB, you can actually populate it as a well-defined model using something called
withConverter. This is the first suggestion I'd make: Use an ORM. From many SO posts I've read, people seem to often fetch plain JSON objects from the db and then begin reading and writing with reckless abandon. That approach seems insane to me and ripe for disaster. âšī¸The only other suggestion I have, and this is more general, but recently I just started getting into TypeScript. Idk if you're working with JavaScript, but if you are-- I honestly can't recommend TypeScript enough. Static type checking and having the IDE (VS Code, personally) work for you is an honest-to-God lifesaver. Because with raw dot notation in JS, God-forbid if you make a typo somewhere-- then you'll just inadvertently end up creating that property in your object and it becomes a huge mess in a hurry.
This is specific to Firestore, but today I actually posted an answer on SO that's related to this. Again, I haven't worked with Mongo at all but I imagine there must be a similar equivalent!
stackoverflow.com/questions/521001...
Hope this helps!