SQL vs NoSQL. Yet another “fight” between technologies. We often find, or hear this stuff. Which one is better? Why? When should we use SQL, when NoSQL? How to scale each of those? And a lot more questions.
Today, we are going to try to explain each of those questions we have, but in an easy and understandable way.
SQL vs NoSQL. Why?
If we want to speak about something, the first thing we need to do is explain terms. SQL stands for Structured Query Language, while NoSQL stands for No Structured Query Language.
Another term that we can often hear, along with these two, are RDB and non-RDB. These two terms explain the most basic difference between SQL and NoSQL at the architecture level.
RDB stands for Relational Database. So, the SQL type database is RDB and NoSQL type database is non-RDB (non-relational).
This is the first difference between SQL and NoSQL.
Databse Schema
The second difference is the database schema. With RDB, SQL, the database consists of tables. Tables have predefined structures divided into columns. Each table consists of one or more rows.
NoSQL consists of document-like schemas. They are created using key-value pairs. The schema of these documents is not permanent, we can change it. That is one of the biggest strengths of NoSQL. This means that we can add, or remove data on every update, even though it’s not advisable. We can take a look at the example below, to understand what we mean by “adding and removing key-value pairs”.
schema User = {
{
id: 1,
username: "John",
items: 29
},
{
id: 2,
username: "Doe"
}
}As we can see in the example above, the first user has key items, while the second doesn’t. This is what it means to not have a predefined schema.
The closest “popular” data type is JSON. NoSQL database schema acts similarly to JSON.
Also, we can often read that SQL means structured data, while NoSQL means unstructured data.
Data manipulation
SQL is one of the most popular query languages. It is pretty easy and straightforward to use. We are basically telling our database what we want to do. It is versatile but pretty strict. Since our database structure must be predetermined we have to create database with a lot of things in mind. One of those things is data manipulation.
SQL offers a wide variety of commands that we can use to effectively CRUD (Create, Read, Update, Delete) our data. Also, it gives us an opportunity to query data from multiple tables at once. And this is one of the strong points of SQL.
At any time we can create queries that we have never used before to retrieve data that we have never queried before. This gives us a huge opportunity to get different samples of data for our application.
NoSQL is different. When we use NoSQL we usually store data in a way that is easy to retrieve. So when we query for data it is in one or two documents, so it is not a problem to retrieve it. Some of the data manipulations can be done in the database, while the rest can be done in the applications’ backend.
Scaling SQL vs NoSQL
This one is probably the reason we are reading this article. SQL databases are usually scaled vertically, by adding more CPUs, more RAM, faster data storage, etc. While NoSQL is usually scaled horizontally, by adding more servers.
This makes NoSQL really suitable for larger data sets. Because we can add just certain number of improvements. But we can have an infinite amount of servers and use data sharding.
In the “fight” SQL vs NoSQL, this gives NoSQL an advantage when we want to work with larger, frequently changing, and ever-growing data sets.
Ideal usage
Even though this is “dangerous” territory we are going to try to explain what is ideal situation for which system.
If we need a database that stores interconnected data then we are going to use RDB, SQL. An example of such a database would be a database for analytics, or a banking system, etc. So anything that is going to retrieve data that is based on other data.
An example of one query (in plain words) would be the following: I want the number of users that have editor roles and that created a post last month.
In a “normal” or small database, this query would check at least two tables to retrieve data. In some systems maybe even four.
NoSQL is ideal for data that is going to change often, or that is not structured. For example, let’s say you have 1 million products in your warehouse. And each of those products have different properties, but you need to store them, along with number of items in warehouse. For this type of job we should use NoSQL.
Conclusion on SQL vs NoSQL
SQL vs NoSQL is something that we will probably continue to hear about. There is no magic formula that will help us decide which is better. But we can decide for ourselves by learning about both of those. Also if we need to decide SQL vs NoSQL, we must consider a lot of facts. And if we are still not sure, we should ask an expert.
If you have any questions or anything you can find me on my Twitter, or you can read some of my other articles like JavaScript find method.