Quiz: What is MongoDB?

Why is MongoDB a NoSQL database?

There are 2 options and although I agree with option 1 (it does not utilize tables, rows and columns), I don’t agree with option 2 (it uses a structured way to access data). You could argue that legacy SQL databases also use a structured way to access data so that wouldn’t be a right answer. Am I wrong?

Is it a true/false type question or multiple correct answers type?

As a definition, MongoDB is an open-source database that uses a document-oriented data model and a non- structured query language. It is one of the most powerful NoSQL systems and databases around, today.

Software genre: NoSQL, Database

Languages used: JSON

A NoSQL database is simply a non-relational database and MongoDB has no relations/ tables.
It is purely a documented oriented database where structure of a document evolves over a period of time and not required to establish structure before in time like in a relational database.
In a relational database, columns in a table are guaranteed to be same for all rows in a table and of same type, where as in NoSQL databases each documents’ field does not need to match, so a field might exist in a document but could be missing entirely from another document and type of field also can be different between documents.
NoSQL databases are suitable for unstructured data where predicting structure of data ahead of time could be difficult and therefore structure of data is different between documents.

MongoDB possess all these and many other features of NoSQL database.

It is a multiple selection question and the correct answer is both option 1 and option 2.

Hi @Fabio_Gil,

Thanks for sharing your thoughts. We will look into it.

Also, here is great definition of No SQL database: https://www.mongodb.com/nosql-explained

cc @yulia_genkina

Hello @Fabio_Gil, @Shravan, and @Ramachandra_37567

This is a great discussion thread, and I would love to weigh in and see what you think about all this.

There are a couple of things on the internet that give people the wrong impression about MongoDB. The first thing is that it is non-structured. By definition, if something is a database, then there is a structure in how the data is stored. This structure could be related tables of data, graphs, key-value pairs, or an alphabetized set of library cards. If there wasn’t structure to the way that the data is stored, it wouldn’t be a database, it would be a datadump of some sort. For example my history notebook from highschool is an unstructured way to store data. There is no way to find information in that notebook other than reading through every single page of it and hoping to find a scribble of relevant information.

This conversation earlier mentioned non-structured query language. The language that is used to query the database is a separate topic. In theory, anything that is not SQL is a non-structured query language, but not because it lacks some sort of structure, but because SQL called dibs on the word structured. It is literally in its name Structured Query Language. When people want to refer to any querying language that is non-SQL they simply say “unstructured” instead of saying MQL, GraphQL, etc.

Another misconception that is floating around the web is that MongoDB is schemaless. Meaning that it lacks schema altogether, and it adds to the misconception that MongoDB doesn’t have relationships. These are not true. MongoDB can easily store related data, enforce schema, and demand structure from the way the data is represented and stored. The key difference here is that there is flexibility in how the schema and relationships are being designed and used, and it isn’t uniform for everyone. Whereas in the world of related tables, there is a strict formula by which related data needs to be organized, and there is no other way to do it, hence, the lack of flexibility in the approach.

Some applications need to ability to have optional fields and a variety of data types in their data, others don’t and MongoDB can accommodate for both by using good data modeling practices, and schema validation rules.

Let me know if you have questions about any of this or if I wasn’t clear at some point in this post.

Hope this helps clear things up a little.


@yulia_genkina what a great explanation. I think what you discussed here goes above and beyond what I needed, I wish I could have liked your post over and over. Many thanks. (and sorry it took me a while to come around and review your reply. MongoDB is a hobby of mine so I only can study when I have free time).