MongoDB: A Document Oriented Database


MongoDB is a Document Oriented Database. Now what is that? Before we get into the implementation level details, we have to check up some of the core concepts. What is a Document Oriented Database? And why do we need it? How does it compare with the traditional relational databases. Let us check out some of these aspects.

Before we understand the advantages and need of a NoSQL, Document Oriented Database, we have to check out some details about a relational, structured database - to understand what was lacking there.

Relational/ Structured Database


First up, we have to understand that there is nothing wrong in Relational and Structural Databases. Traditional databases like Oracle and MySQL, and also some modern databases like Postgres, have been very popular among developers. Several enterprise scale applications are efficiently supported by these databases and they continue to grow.

When we use a relational or structural database, an important concern while modelling data is identifying the tables where we can segregate the data. We have to identify the tables such that we can place structured data in each, and plan a good relation between the data in different tables.

To understand this, let us consider the good old employee database.

Emp_idNamePhone_numberEmail_idSkillDesignationSuperior
1Cierra Vega(236) 897-6800cierra.vega@thewiz.comMongoDBSoftware Developer3
2Alden Cantrell(934) 580-5967alden.cantrell@thewiz.comReactJSSoftware Developer3
3Kierra Gentry(969) 282-3183kierra.gentry@thewiz.comFull StackTech Lead4
4Pierre Cox(697) 753-5031pierre.cox@thewiz.comEnterprise ArchitectureArchitect5
5......

This worked quite well - when our data was restricted to one phone number, one email id, one skill. The structure of the data enabled super fast query, and compact storage.

But, over the years, the availability of higher processing power and disk space, have also increased the demand. Now, we store a lot more data per employee. Each employee has multiple skills, at least two phone numbers, and several email ids. Also, the modern employee database tracks a lot more than these basics.

For example, if we want to save the following details for a given employee

  • Basic Information: Employee ID, Name, DOB,
  • Contact Information: Address - including primary, current, etc., Phone numbers, Email ID's
  • Skills: Set of skills and confidence level
  • Performance History: All the performance related observations so far
  • Aspiration: All the defined aspirations and goals
  • Hierarchy: Designation, Subordinates, Supervisor, Reporting Manager - could be different from Supervisor

If we want to store all this data in a relational database, it would require a really complex table structure. And also, a complex code to work with it.

Document Oriented Database


With a document oriented database, we break a lot of those barriers. In MongoDB, we do not have tables and columns. Instead, we just have a collection of documents. This document is essentially a JSON Object.

Unlike the columns, in a table, the fields in this document need not be root level elements. We can have a complex structure of sub-documents and arrays within the document. Also, MongoDB does not impose any restrictions on the contents of this document. Each document in the collection could be entirely different from the others.

This can also be restricted if you like, by configuring collection level validations. Thus, MongoDB provides a flexible data model, and also allows you to restrict it.

Coming back to our employee database, we can save all the data above into a single collection - one document per employee. We can do so, while allowing simplicity, ease of access and high performance.

An employee document would look like this:

{
	_id:"307d44eb-360e-4bad-94de-1d466422c4f3",
	basicInformation: {
		prefix: "Mr",
		name: "Thomas Crane",
		dob: ISODate("1971-01-01T00:00:00.000Z"),
		nationality: "USA"		
	},
	contactInformation: {
		address: {
			current: "3230 Ross Street, Collinsville, Illinois",
			permanent: "60  Harley Vincent Drive, Garfield Heights, Ohio"
		}
		phone: ["618-205-0397", "217-802-3829"],
		email: ["thomas@thewiz.com", "thomas.crane@gmail.com"]
	},
	skills: [
		{skill: "MongoDB", domain: "Database", level: "professional"},
		{skill: "AWS", domain: "Cloud", level: "professional"},
		{skill: "Flutter", domain: "Mobile", level: "expert"},
		{skill: "PyTorch", domain: "AI/ML", level: "trained"}
	],
	record: [ {
			project: "Order Management Mobile App",
			description: "Develop a serverless Order Management App.",
			technologies: ["Android", "AWS Serverless Framework"],
			duration: 3,
			year: 2020,
			performance: 8
		}, {
			project: "MongoDB Tutorial",
			description: "Develop a tutorial for MongoDB.",
			technologies: ["MongoDB", "Documentation"],
			duration: 2,
			year: 2020,
			performance: 9
		}
	],
	aspiration: [
		{goal: "Expertise in MongoDB", duration: 1 },
		{goal: "TOGAF Certification", duration: 1 },
		{goal: "Expertise in Serverless Architecture", duration: 6 }
	], 
	hierarchy: {
		subordinates: [
			"58715dab-937b-482c-b7c0-135d93ab59ef",
			"1792ae19-bd46-47a5-bfb2-0fc0a9ec9478",
			"71a6a8f4-2805-4d90-9f07-0f70162a62d3"
		], 
		supervisor: "39f19cea-547a-490f-87d0-23235ee23268",
		manager: "d7aa72c7-672f-4f3d-a883-6f902b65aea4"
	}
}

This JSON document has basic elements that are valid for any employee, and also some elements that are unique. They all fit in well, because of the flexibility of the database.

MongoDB also provides us with efficient querying and indexes - that enables fast queries on a massive data.