Database systems are the mainstay of applications. Without databases, it would be extremely difficult to store data in an organised manner or extract it quickly and easily. However, over the last five years, there is a shift in the type of database systems that are being used. There is a steady increase in the number of users who are adopting NoSQL databases in favour of traditional relational databases. Why is it so? First of all, what are NoSQL databases and what are relational databases? Over the course of this ‘Say NO to SQL series’, you will have all the answers.

Relational database: The venerable workhorse

Let us look at traditional databases first. These are called relational databases. Relational databases are to the world of data, what the steam and diesel locomotives are to railways. Based on the needs of the time and the resources available, they sprang up and became really popular until they were ingrained as the go-to method. But just like railways all over the world are undergoing electrification and even magnetisation to realise higher speeds and reduce local emissions, relational databases have their own limitations and are being replaced by NoSQL databases widely.

The term ‘relational database’ is too technical. Let me simplify it for you.

Imagine that you have the following list of contacts.

Serial Number	Name	Phones
1	Sanjaya Chowdhury	Personal: 9422515373 Work: 9758085846
2	Purushottama Kulkarni	Personal: 9169362975 Backup: 9707818584

While this is a convenient list for us to look up, it does not fit under the rules of relational databases. These rules are:

1. All columns must ONLY have data that cannot be broken down further.
2. One combination of a row and a column can have ONLY one value.

Our table violates both the rules. The serial number column is okay. However, the ‘name’ column can be further broken down into the different parts of a name, e.g. first name, family name and the like. While this is not mandatory, a well-designed relational database will not combine fields which can possibly be broken up.

The ‘phones’ column fails both the tests. For one, there are two different types of ideas combined together, i.e. the type of phone and the phone number itself. Secondly, all the phone details of a person appear in the same column.

A well-designed relational database looks something like the following.

Contact serial number	Own name	Surname
1	Sanjaya	Chowdhury
2	Purushottama	Kulkarni

Contact serial number	Phone type	Phone number
1	Personal	9422515373
1	Work	9758085846
2	Personal	9169362975
2	Backup	9707818584

The bits of information which were combined in the original table have been broken up into other tables and both tables have common columns, which help us match the information. The common column is contact serial number. When we want both the name and the contact numbers of a person, we extract the information from the two tables based on the common serial number. This process is called ‘joining’ the two tables.

This is the basic principle of relational databases. Information goes into multiple tables that break up that information into bits which cannot be further broken. When we want information from different tables together, we join the tables again.

Database solutions like Oracle, MySQL, Sybase, Microsoft SQL and PostgreSQL function this way.

The new age: NoSQL databases

NoSQL databases do not impose the above restrictions and one can store tables with various combinations of information without breaking them up. This keeps all the information at a glance, i.e. we do not need to look up information broken into multiple tables. The very first table in this post is valid for NoSQL databases.

Over this series, we will be looking at the different types of advantages provided by NoSQL databases over relational databases and how it affects the applications we write.

MongoDB, Cassandra, CouchDB, Riak and Apache HBase are some popular examples of NoSQL solutions.

But why No ‘SQL’ and not No ‘Relational’

Okay, okay, you got me there! Your question is 100% valid. NoSQL is actually a misnomer and NoRelational makes more sense. But the former name has unfortunately stuck, so let us understand its etimology.

Flashback to 1980s and early 1990s. Databases were getting widespread adoption, but only three or four major database solutions existed. They were all relational databases: Oracle, FoxPro, Sybase and Ingres. They all did a great job. These were the days of command-line access and each solution came with its own set of proprietary commands to store and access data. It was like learning Greek, Hindi, Swahili and Japanese. No similarities between any of them.

To address to this problem, the major companies like Oracle, Microsoft and others put their heads together and finalised a standard language for database operations across different solutions. Originally the brainchild of Oracle, the Structured Query Language or SQL (pronounced as es-que-el as I do, or sequel like many do, both are correct) was accepted, polished and improved over the next decade, starting a revolution for relational databases. Anyone with proficiency in SQL could transfer his/her skills from Oracle to Microsoft SQL Server, from Microsoft FoxPro to MySQL… and anything in between. The standardisation fostered the growth of open source database solutions like MySQL, PostgreSQL and FireBase, with the first one becoming an instant hit as a part of the LAMP (Linux, Apache, MySQL, PHP) stack and spurring the development of wonderful software solutions like WordPress, which now powers this blog 😉

When non-relational databases came along, they initially looked at SQL as their language of choice, so that the switch from relational databases would be easy. However, SQL by design was made for tables with unbreakable information bits in mind and it did not fit very well with the concept of combined information. So the engineers of the various NoSQL solutions had to drop SQL altogether and the movement came to be known as NoSQL, which simply means that you need to completely shift your mind from the ‘SQL way’ of doing things.

This is similar to the way we say about human languages, where if you really want to learn French, you must stop thinking sentences in English and translating them word for word. Rather, you must transition to the ‘French way’ of thinking. Hence, non-relational databases force you to stop thinking of solutions that fit into SQL instructions, hence the term ‘NoSQL’.

Conclusion

In this post, we have seen how relational and non-relational databases differ in their structures. Further posts in this series will zoom into each problematic area of relational databases, that is solved by the NoSQL databases.