An Introduction to MongoDB

Hello and warm greetings to all our dear followers. In this series of posts, I will explore various topics related to the MongoDB database. These topics include its differences from MySQL, how to perform CRUD operations, establishing relationships between data in MongoDB, and many other subjects. Throughout this series, I will also develop several projects, so in addition to theoretical discussions, I will be working with MongoDB in a practical, hands-on way.

The first question that comes to everyone's mind is: What is MongoDB?

MongoDB is the name of the company that designed the MongoDB database. So, the name of the database and the name of its developing company are the same. The main goal behind MongoDB's design was to store extremely large volumes of data (in terms of quantity).

The world of MongoDB, like that of MySQL, consists of multiple databases. In MySQL, we have tables within each database. But in MongoDB, these are called collections (meaning a group or set). So, we can have many databases, each containing multiple collections. Within each collection, there are numerous documents. If you've seen documents before, you know they are essentially JavaScript objects. In other words, data in MongoDB is stored in the form of JSON objects.
Take a look at the following JSON object:

{
    "name": "albro",
    "age": 26,
    "skills": {
        "backend": "PHP",
        "frontend": "JavaScript"
    }
}

The entire code above is called a document. Also, name: "albro" is a key (or field), where name is the field name and "albro" is the field value.

In the skills section, we see a JavaScript object being stored as a value! This means that in the world of MongoDB, we can store values in a nested format. This is a major advantage over MySQL, because in MySQL, retrieving multiple related pieces of data often requires complex JOIN operations across several tables. But in MongoDB, we can easily store all relevant information for a specific data entry inside a single JavaScript object and retrieve it all at once.

Of course, the document above doesn’t show all possible structures. We can also use an array as the value of a key, where each item in the array is a different JavaScript object.

So, you have complete flexibility in how you manage your database.

You may have heard that data in MongoDB is stored in BSON format. The word BSON comes from JSON and binary. Since MongoDB converts your data into binary format behind the scenes, it uses the term BSON instead of JSON to reflect this process.

However, this conversion happens in the background and doesn’t concern us directly. The reason for converting data to binary is to increase performance, as working with data in binary form is significantly faster.

Another interesting aspect of MongoDB that sets it apart from MySQL is that MongoDB databases are schemaless—meaning the structure of the data is not predefined. For example, within a single collection, you can store many different types of data with varying structures. But that’s not the case with MySQL. If you’ve worked with MySQL before, you know that the structure of the data in a table must be defined upfront, and changing the table’s structure later on can be quite difficult.

The advantage of having no predefined schema is that your database can grow and evolve alongside your application, making scalability much easier and more flexible.

Overall, the philosophies behind MongoDB and MySQL are fundamentally opposite. For instance, in MongoDB, relationships between data are far less emphasized than in MySQL—you can even choose to have no relationships at all between your data.

Of course, storing data without a predefined structure can lead to a messy database. So when I say MongoDB is schemaless, I don’t mean chaotic data—I mean you, as the developer, have the freedom to shape the structure as your application evolves.
It’s your responsibility to eventually define a relative structure for your app so that data is stored in an organized way (every application needs order to function efficiently).

Imagine you’ve been running a website for a year. If you want to change how user data is stored and you’re using MySQL, you’ll face many challenges—because the structure of that data was fixed from the beginning. For example, each user might be required to have a name, email, and profile picture. Now suppose you want to add a phone number and remove the email. In MongoDB, this change is relatively easy. But in MySQL, you’d have to manually go into the database and restructure the tables, which can be quite a hassle.