Guide to NoSQL Databases for Developers

So first and foremost: what are NoSQL databases and why should I care about them? The easiest way to understand the definition is that NoSQL databases are not SQL databases. Standard relational SQL databases such as Oracle’s SQL server or MySQL have a tabular structure, similar to what you’d see in an Excel spreadsheet. Whereas NoSQL databases have various types of formats and can therefore be more flexible.

For example, imagine that you had to build an application where users were able to define their own fields, such as a survey application where one user may create a survey with two fields and another may create a survey with a hundred fields, and they need to have the ability to be named on the fly. Technically it would be possible to implement this with a relational database, however it would be very clunky. However NoSQL databases could handle this easily, by allowing the fields to be created dynamically and then each record would could be stored with its unique characteristics.

It’s important to note that one of the greatest strengths of NoSQL, it’s flexibility, also presents its greatest challenge. Imagine that you are building out an inventory application that has fields that need to connect to other tables, such as a user table for the employee entering the information, a vendor table, and a tax table to calculate depreciation. If you were to attempt to implement a NoSQL database for this inventory option you’d end up having to work very hard to map the values between the models and it would also make for a very difficult application to maintain. In this case study a relational database (rdms) would work perfectly.

So when you’re trying to decide on which database to use, it really comes down to what the requirements of the application are. If you wanted to chop a tree down you wouldn’t use hammer, you’d use an axe because it’s basic common sense to utilize the right tool for the right job. And it’s the same way with software development, I don’t believe in the SQL vs NoSQL debate, they are both tools and they are the most effective when used in an application that works well with their strengths.

A good rule of thumb is to simply follow the guidelines given by the names themselves:

If you have data that relies heavily on relationships then it’s probably the best fit to utilized a relational SQL database.

If you have an unstructured data set that needs flexibility, than it may be the best option to go with a database that is Not SQL, such as a NoSQL database.

For an example of how NoSQL looks, here is a snippet from a MongoDB database:

Notice how it really just looks like JSON code? It actually is using a form of JSON called BSON, short for Binary JSON and it really is just a set of key value pair data stores that can be structured however your application needs.

This is in comparison with this relational SQL table, notice how NoSQL databases encapsulate all of the data into a single object whereas the SQL structure is built around relationships?

That’s really the key difference in understanding how they work.

If you’re interested in building applications with NoSQL databases it’s important to understand that there is no such thing as a standard NoSQL database, there are many different variations. There are Key/Value pair stores, wide-column family stores, document databases, and graph databases. I’ll place a link in the show notes where you can explore each type and see what will work best for your application.