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 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.


What is NodeJS?

I have been researching new open source offerings and came across a platform called NodeJS; which at first glance seems to be simply a JavaScript command line interpreter, but in reality is much more. I have heard things about NodeJS before but have never had the chance to take a look at it. Node is built on top of Google’s V8 JavaScript engine which powers JavaScript processing in the Google Chrome browser. To date V8 is one of the fastest JS engines around.

Node is also great for those familiar with JavaScript but haven’t ever had the chance to delve into more complex server side development. Yet Node is far more than a simple JavaScript CLI because it ships with a large variety of features like an HTTP library and a TCP library. Node also seems to have the ability to simplify threading (which can be a daunting task even for experienced developers) by offering functions like setTimeout and setInterval, events can be handled with ease.

The platform advertises itself as non-blocking, meaning that when a program is waiting for something to do it remains idle, rather than sleeping. This allows more efficient processing of concurrent real time events. The video below also suggests that Node would be an excellent candidate for a streaming server because of the way it handles concurrency.

Node is also incredibly simple to use. Those familiar with Python know how typing “python” at the command line brings up a “python” command prompt where you can execute code directly from the terminal and if you pass in a file after python, that file will be executed. Well, NodeJS works the same way.

Here’s a simple web server taken from the NodeJS homepage:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, '');
console.log('Server running at');

Right now, those involved with the development recommend building from source due to the rapid changes that are being made to the code. It is as simple as a configure, make, install. Additionally, it seems NodeJS is best experienced with Unix/Linux based operating systems but better Windows support is in the works.

Check out this video where Ryan Dahl introduces node during a San Francisco PHP Users Meet up. It covers many of the features Node has to offer and is pretty entertaining as well.

This seems to be pretty cool and most likely will become very popular, especially with cloud services like Windows Azure and Amazon EC2. Check it out and stay ahead of the learning curve.

Use jQuery from the Google Libraries API

So you’ve decided to join the web 2.0 fad and have taken up learning jQuery on your website. If you aren’t too familiar with the terminology, deciding which file to use can be a little vague. There is the production version and the minified version of the library you can download at While developing you should use the development version. Inversely, while in production you should use the production version; enlightening, I know. More often than not when you find a JavaScript library or plugin on the internet these two versions will be offered. Although functionally equivalent, their size isn’t. The reason for this is that JavaScript is executed on the client side; therefore, the script you reference in your page has to be transferred to the client over the internet. To keep bandwidth costs low for sites that might experience higher traffic, many opt to go with the minified version because it is so much smaller.

It’s a pain to keep and manage many different versions of jQuery in all of your different environments. This is where Google comes in to play. The developers at Google have taken the time to build a wonderful API for referencing jQuery and many other JavaScript libraries as well. In addition, you also get the power of Google’s CDN or content delivery network. This means that Google will handle the bandwidth for retrieving these scripts for free and also that they manage the caching for you. Additionally, they have a global CDN that can speed things up when users access your site from a location that is far away from where your physical servers reside. Sounds good to me!

Using the Google Library APIs couldn’t be easier. All you have to do is place a few lines of code (similar to what you would do already when referencing jQuery) in the header of your HTML.

For example, I am building a site that requires the latest version of jQuery and also would like to include jQuery UI. Referencing these libraries is as simple as:

<script type="text/javascript" src=""></script>
<script type="text/javascript">
    google.load("jquery", "1.7");
    google.load("jqueryui", "1.8");

Now you are all set to use jQuery and jQuery UI without having to download anything or set up caching rules. Additionally, if you ever want to upgrade to the newest version of anything all you have to do is change the google.load call in the HTML. Pretty simple! They support many of the popular JavaScript libraries available today. At the time of writing these are:

It is worth noting that you can also use jQuery hosted by Google without using the Loader API and get the same CDN benefits by including the following (but that’s not nearly as cool!):

<script src="//" type="text/javascript"></script>

So next time you’re developing a jQuery application, keep this article in mind and stop worrying about managing dependencies. Get right into the code!

%d bloggers like this: