Relational vs Non-Relational Databases
Key Points
- Relational databases store data in structured, interconnected tables where each table represents a single entity such as customers or orders.
- Each record within a table is uniquely identified by a primary key (e.g., customer ID, order ID), enabling precise retrieval and reference.
- Relationships between tables are created by linking foreign keys (e.g., an order record includes the customer ID to indicate who placed it), allowing complex queries across entities.
- This tabular, schema‑driven approach ensures data integrity and consistency but requires a predefined structure, contrasting with the flexibility of non‑relational (NoSQL) databases.
Sections
- Relational Databases: Tables and Keys - The speaker outlines how relational databases store data in interconnected tables, using primary keys to uniquely identify each record.
- Customer‑Order Relationship via Foreign Keys - The speaker explains how linking a customer table’s primary key to an order table’s foreign key lets you identify which customers placed which orders, illustrating relational database benefits like data consistency, ease of management, and enhanced security.
- Why Choose Non-Relational Databases - The speaker highlights flexibility, horizontal scalability, and cost efficiency as key reasons customers prefer non-relational databases over relational ones for modern applications, while noting relational databases suit structured, traditional workloads.
Full Transcript
# Relational vs Non-Relational Databases **Source:** [https://www.youtube.com/watch?v=E9AgJnsEvG4](https://www.youtube.com/watch?v=E9AgJnsEvG4) **Duration:** 00:08:06 ## Summary - Relational databases store data in structured, interconnected tables where each table represents a single entity such as customers or orders. - Each record within a table is uniquely identified by a primary key (e.g., customer ID, order ID), enabling precise retrieval and reference. - Relationships between tables are created by linking foreign keys (e.g., an order record includes the customer ID to indicate who placed it), allowing complex queries across entities. - This tabular, schema‑driven approach ensures data integrity and consistency but requires a predefined structure, contrasting with the flexibility of non‑relational (NoSQL) databases. ## Sections - [00:00:00](https://www.youtube.com/watch?v=E9AgJnsEvG4&t=0s) **Relational Databases: Tables and Keys** - The speaker outlines how relational databases store data in interconnected tables, using primary keys to uniquely identify each record. - [00:03:14](https://www.youtube.com/watch?v=E9AgJnsEvG4&t=194s) **Customer‑Order Relationship via Foreign Keys** - The speaker explains how linking a customer table’s primary key to an order table’s foreign key lets you identify which customers placed which orders, illustrating relational database benefits like data consistency, ease of management, and enhanced security. - [00:06:25](https://www.youtube.com/watch?v=E9AgJnsEvG4&t=385s) **Why Choose Non-Relational Databases** - The speaker highlights flexibility, horizontal scalability, and cost efficiency as key reasons customers prefer non-relational databases over relational ones for modern applications, while noting relational databases suit structured, traditional workloads. ## Full Transcript
Hi, everyone.
Today I'm going to be talking to you about relational versus non-relational databases.
These are two different ways in which clients store the data that they have and operationalize it.
And we know there is so much data that is coming into every single company today
that it's important that customers have options for how they want to store that data.
So, let's start with relational databases.
Relational databases are a very structured way to store your data.
But to really understand a relational database, first we need to understand a table.
So all the data is stored in tables and those tables are connected to each other.
That's why we have the name "relational" and we see a relation in the name
because all these tables connect to each other.
They all have relations with each other.
So let's start with one table.
We have our customer.
So each table revolves around a single entity.
And with our customer, there is a lot of different information that we would want to know about them, right?
We'd want to know what their first name is,
their last name,
maybe their date of birth, their email,
and etcetera, etcetera, whatever other information would be relevant to know about the customer.
But we might also have customers that have the same first name or the same last name,
and we need a way to uniquely identify each customer.
So that's why we have our primary key, which is our customer ID.
And this is a unique identifier for each record in this table.
But like I said, with relational databases, we want to view each table as it connects to other tables.
So let's think about what a customer does.
A customer places an order, right?
So an order is actually a separate entity that would connect to our customer table.
So let's draw out our order table.
And what would we want to know about an order?
We'd want to know maybe what time it was placed,
what items are in it, and whatever else you think is relevant to know here.
But again, like with the customer ID, we need a unique way to identify each order.
So we have another primary key here called an order ID.
And if we look at each of these tables and we look at the data in them, we can really see how they connect to each other.
So let's take a customer table, for example.
We know we have all these different pieces of information that are relevant to know about the customer.
So I'm going to start with the customer ID.
And then we have their first name, last name, etc..
So like we said, each customer ID is unique.
There's only one for each record in the database.
So we have our first customer, let's call him John Doe.
Our second customer, let's say, is named Jane Smith.
And third customer.
We can just continue populating information about every single customer that we have.
And then with our order table, we start with our order ID,
and we have other information that we want to know, right?
Time, items, etc..
But what we also need to know is which customer placed what order, right?
So, in order to do that, we actually connect the customer ID to the order table.
So we take this information and we move it over here.
So in the customer table, this is the primary key.
But when we move it over, this becomes the foreign key.
So now we can add in our customer ID here.
And we have our first order.
It's placed at this time.
Second order.
Third order.
And looking at our customer ID, let's say that this is 1.
And our second one is 2, our third one is also 2.
And now we can see, through connecting these two databases,
that customer John Doe made the first order.
We see what time, what items.
He also made the second order, and Jane Smith made the third order.
So as we can see with relational databases, this is a very structured way to view the information that's coming into a company.
But with that, there's a lot of benefits that come in.
So one of them is that the structure really ensures data consistency.
And you can see that all the data that we have over here is very consistent, right?
We can see that it's easy to manage that data and easy to get an overview of what is in your database.
This also helps with security.
So, let's say that you are in hospital and you have a lot of patients.
You have information about their medical history, what medications are taking.
That is all protected information.
So through using a relational database, you can encrypt certain tables,
you can hide information,
and you can make sure the right people have access to the right data.
And then finally, we have ease of backup and recovery.
So, because this data is very consistent and at all times it remains consistent,
it's easy to save the database at any point and easily recover from what you recently had.
So this gives us an idea of what a relational database looks like.
Now on the other hand, we have non-relational databases.
So this is a break from the very structured approach of a relational database.
There are a few different types of non-relational databases.
First, we have key value databases.
And this shows data as a key and a value, right?
We have one key that ties to one unique value.
Another key that ties to another unique value.
And you can retrieve these values through plugging in the keys and getting that information back.
We also have column store databases.
And this stores data in separate columns and is optimized for performance.
And then we have graph databases.
So this shows different entities in the database and how they connect to each other in a graphical way.
And finally, we have our document store databases.
So this has data and documents, and a group of documents is called a collection,
and you can essentially retrieve the information as it relates to a single collection.
So you see that there are a lot more options here with the non-relational databases.
And that's really why customers might choose a non-relational option as opposed to a relational one.
There is added flexibility in going with a non-relational database.
So that's really one of the key differentiators and why customers choose non-relational over relational.
And it also has high scalability.
It's easy to scale non-relational databases out horizontally
and this means that they can essentially scale out without adding more resources.
And finally, cost effectiveness.
And this ties back into the scalability, right, because you're not adding more resources, but you're able to scale out and add more data in.
So we see that we have a lot of different ways in which customers can store their information
and make sense of all the data that's coming into the company.
There are different ways that people can leverage both of these databases.
There are different use cases.
People might use relational databases for more traditional workloads.
If you have a point of sale system, if you're tracking a large amount of records and you want to do so in a very structured way,
then relational databases might be what you go for, for that.
But if you're developing a new application, you want added flexibility,
then customers might defer to a non-relational database.
But either way, our clients have options as to how they want to store their data and how they want to best operationalize it.
Thank you.
Thank you.
If you like this video and want to see more like it, please like and subscribe.
If you have any questions, please drop them in the comments below.