MongoDB – What’s the difference?

logoWith the social state of the Internet today more and more people are building web applications and getting started exploring the world of software development. However, with the direction social media and users of these applications are taking, little has been done to improve the tried and proven components that make up a web-based application.

Traditionally, you needed three pieces of software to get put together a dynamic application: a webserver, such as ApacheIIS, or lighthttpd, a web programming language interpreter, such as ASP.netPHP, or Java, and a relational database server, such as MySQLOracle, or PostgreSQL. Each piece of the puzzle presents different challenges for aspiring developers.

In my experience, setting up the data abstractions layer for any application can be one of the most frustrating parts of the development cycle. It can be a very time consuming process and doing it the right way can even take longer. Learning to properly create tables with appropriate indexes, manage constraints properly, and normalizing data structures takes a long while to master. DBAs (Database Administrators) make a living doing this; therefore it isn’t feasible to become an expert overnight.

To start explaining MongoDB I will first describe the what a normalized relational database would look like for storing recipes. Please note: this is a very high level overview and doesn’t take into consideration standard practices such as logging and security.

A normalized recipe database ERD (entity relationship diagram)

A normalized recipe database ERD (entity relationship diagram)

This ERD shows that users can own recipes, a recipe has a title and instructions, and a recipe contains 0 to many ingredients. This is a very simple example, but it’s easy to see how proper design can be a daunting task. After the design is done, the next part comes: accessing the data.

Before I continue, I am well aware of products such as NHibernate that abstract away data access code and that ORM (object relation mapping) tools can even create the database based on your class structure. However, I am strongly opposed to ORM tools because they create a direct dependency on the framework you use and additionally can create horrific management issues down the line during a software product’s evolution. Also, they are just plain slow! For more information about why some people don’t like ORMs, click here.

MongoDB doesn’t work like a traditional RDBMS (relational database management system). By nature, MongoDB looks at records in a completely different way. Instead of having tables, MongoDB has collections of documents. What is a document? If you are familiar with JSON you already know what they are. A document is a key-based group of information. A key is simply a way to separate documents.

To do what we did in the above example with MongoDB, we don’t need to go through the modeling and design step. Instead we just need to define a key. The recipe database contains a natural key that we can use: the USER_NAME. Every user of the website will have his or her own unique username, therefore, that’s our key. To dive right in, here is an example of how a document would look like for a users recipe he or she added.

"user_name": "jeffrey.pry",
	"recipes": {
		"recipe": {
			"title" : "PBJ Sandwich",
			"description" : "An American favorite, the peanut butter and jelly sandwich.",
			"directions" : "Spread PB&J onto one piece of bread and then cover with the other.",
			"ingredients" : {
				"ingredient" : {
					"name" : "Peanut Butter",
					"quantity" : "2 Tbsp"
				},
				"ingredient" : {
					"name" : "Jelly",
					"quantity" : "2 Tbsp"
				},
				"ingredient" : {
					"name" : "Bread",
					"quantity" : "2 Slices"
				}
			}
		}
	}

As you can see, MongoDB works similarly to how JSON looks. This example is one JSON document that can be placed into a collection. Then in the application, you can just select the username by the key and return the serialized document like the one above. Simply enough, if we wanted to add a new field such as a tag to a document in our collection, you just add it, plain and simple. No need to drop tables or alter constraints.

To try MongoDB out and go through the excellent tutorial, head on over to http://try.mongodb.org/ where you can work with a live tutorial and issue commands to a real MongoDB shell for free.

To make it even easier, the MongoDB drivers that are available allow you to directly store objects into a collection and query them easily. Although this article doesn’t go into great detail about the inner workings about MongoDB, I encourage you to do some research of your own. MongoDB isn’t the best tool for the job 100% of the time, but learning the differences between a NoSQL database and a traditional RDBMS can help you expand your horizons and bring the best tool for completing your project to the table.

Advertisements
%d bloggers like this: