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.