In my first post comparing the two database systems, I didn't actually compare them at all. I wrote a bit about Mongo and getting over a stumbling block that I had while using it for the first time. It was the kind of stumbling block that helps you to learn something better than if everything was just smooth sailing. Going from why isn't this working? to this is how it works can be very frustrating but also very productive.
But still, what about the comparison?
I started out with the question of why Mongo at all but decided that was going to be a path too far. I had a sprint to work on after all, so I limited my query to answering the question How do you structure Mongo schemas?. Like, how do I even think about the data in the first place, and do we have to think about 1-to-N and N-to-N type relationships etc?
I read two short documents on MongoDB to answer that question
6 Rules of Thumb for MongoDB Schema Design
MongoDB - Data Modelling
, leaving a bunch of bigger questions to be answered at a a later time. Questions like:
- What's the deal with non-relational databases?
- What's the deal with having a field that's an array. And for that matter an array of non-prescriptive length.
- What are the performance considerations or just any of the considerations when deciding what type of database to use?
So what do I know so far?
Here's what I've learned.
Mongo gives you flexibility to design your schema according to the needs of your project. I think about that in comparison to a SQL schema where I always think about normalization and foreign keys.
You can containerize data according to logical relationships. If a person has pets, you can store the Pet info (name, species, etc) inside of a Person model.
Designs like Pet-Person above can have a drawback where you need only the Pet info. With this kind of design, you would need to access the Person first.
Foreign and Primary keys exist in Mongo but they're called 'references'. I don't know anything about the mechanics of references.
Certain Mongo schemas seem more convenient but less efficient.
All in all, I have very little understanding of what's going on. But I had enough working knowledge to create a very simple non-referencing model for our Mongo/Full-stack sprint and also in yesterday's TA (this was supposed to be yesterday's post).
Top comments (0)