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!
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!