Documents

MongoDB is a NoSQL Database Management System (DBMS). This means that it eschews the traditional table-based data storage model used by SQL-oriented systems such as MySQL, Oracle, and Microsoft SQL Server. Instead, it stores data as documents, which are data structures that are almost identical to standard JSON objects. For example, a MongoDB document can look like this:

{
  "_id" : ObjectId("547cb6f109ce675dbffe0da5"),
  "name" : "Fleur-De-Lys Pharmacy",
  "licenseNumber" : "DL 133",
  "address" : "430, Triq Fleur-de-Lys",
  "geolocation" : {
  "lat" : 35.8938857,
  "lng" : 14.46954679999999
  },
  "postCode" : "BKR 9060",
  "localityId" : ObjectId("54c66564e11825536f510963")
}

This document represents a pharmacy, with some basic information such as the name, address, and national license number. If you are familiar with JSON, you will feel right at home; this is the standard object notation. However, note an unusual datatype in here—the ObjectId. This is a built-in datatype in MongoDB, and it is the default method that is used to uniquely identify a single document. Every single document you store in a MongoDB database is guaranteed to have a unique _id member with respect to that database.

Collections

Even though you can uniquely identify a document by its _id, life would be a lot simpler if we could somehow organize documents according to some common characteristics. This is where the concept of a collection comes into play. Simply put, a collection is nothing more than a group of documents that exist in a common folder. For example, we can have a collection named Pharmacies, which will store documents like our preceding example.

If you are used to SQL, you may instinctively feel that the documents in the same collection must somehow have the same structure, just like rows in an SQL table do. Surprisingly, this is not even remotely true. Collections only group documents; they do not impose any structural demands on them (apart from the need to have an _id, but this holds for all the documents and has nothing to do with a particular collection). This means that in the collection that we store our pharmacy-related data in, we may also store documents that describe fruit, people, cars, or movies. Whether we should do so is left entirely up to the programmer. This great freedom of structure is one of the most powerful aspects of MongoDB and a key factor that sets it apart from the more traditional DBMS.

Databases

We now know that MongoDB stores data as documents in collections. The last storage concept that we need to mention is the database itself. Simply put, a database in MongoDB is a top-level organizational structure, which holds a group of collections along with information about users who may access the database, security settings, optimizations, and other configuration options. A single MongoDB instance can manage as many databases as server resources will allow.

An example – a product order database

Let's put what we have learned so far into practice and construct a simple MongoDB database that contains data about products, customers, and the orders that the customers have made for specific products. If you are accustomed to other DBMS such as MySQL, you may be surprised to see how simple and intuitive the process is.