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. ☹️
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!
Hope this helps!
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
For further actions, you may consider blocking this person and/or reporting abuse