Up until today, we have only been working with 1 table at a time. But in SQL, you will be dealing with a lot of them, yes, a lot!
In order to link them to each other, we use Joins based on common identifiers that will allow you to access information from multiple tables. You'll see, this is so powerful and will scale your game in SQL.
Imagine Facebook needs to keep track of tons of data, right? Think about how they might store all the stuff we post. One way could be like having a giant spreadsheet where every row is a post. You've got a column for the post's text, one for when it was posted, who posted it, and so on.
You still here? Now, think about the person who posted it. We're not just talking about a name; we're talking about their whole Facebook profile – their photos, friend list, likes, everything. Facebook could, in theory, cram all that info into our giant spreadsheet for every single post.
But what if you update your profile picture or add a new interest? If Facebook kept all your info in that same giant 'posts' spreadsheet, they'd have to go back and change your profile info on every single post you ever made. If you've shared, like, a thousand posts, that's a thousand updates. Multiply that by millions of users updating their stuff all the time, and Facebook's computers would be swamped!

So, what they do instead is split the data. They have one table just for profiles – let's call it the 'users' table. It's got one row for each user with all their profile details. Then, there's another table just for posts. Every time someone posts, it goes here, but this table doesn't store all the user's profile details – it just has enough to identify which user made the post. Feeling better now?
When Facebook wants to show you a post, they do a quick match-up. They take the user info from the 'users' table and combine it with the post info from the 'posts' table. This way, they only have to update your profile in one place, and it still shows up correctly everywhere on Facebook. Smart, huh? It saves a ton of time and computer power.

Now, that you understand why we actually need multiple table.