So now we move on to tables.
This is the real heart of SQL.
Yes, we make a new database.
We use a database that's important to know.
But like I said previously, we do that occasionally, but then we constantly work with tables and the
data inside of tables within a given database.
So we have this empty shell of a database or maybe multiple empty shells of databases.
They have nothing in them.
Tables are what we need to put in those databases so that we can hold data.
So you may have heard the term table before.
A database is really just a bunch of tables.
Now, when I say database, that only applies to a relational database.
If we're talking about something like MongoDB, that's not a relational database.
So it doesn't use tables, but all the SQL flavored database variance, they all consist of a bunch
of tables and tables are what hold our data.
They describe the format and the shape of our data, and then they hold collections of data that follows
that shape.
So a more technical definition would be a table is a collection of related data held in a structured
format within a database.
Now that structured part is very important.
Also, the fact that it's a collection of data is very important.
So let's say that we were working with cats data.
We're building a pet shelter or a vet database or something.
This would be one way to structure my information.
I could say this is what a cat looks like in our database.
This is the cat's table.
Every cat has a name.
Every cat has a breed, every cat has an age.
I'm defining the structure.
That's the first part of a table, and it will start empty.
This one is not empty.
And then we insert data into the table following that structure.
So every cat has a name, a breed, and an age.
So some basic terminology we call the headings or the headers of each table columns.
So this table has three columns.
Now I'm visualizing it here right as an actual table.
It's not stored this way.
It's stored as some compressed thing that looks nothing like human readable code, but it will be displayed
to me nicely in the same way that we see this right here.
Print it out.
It looks like a table.
But again, this is just a slide diagram that I'm drawing for you.
This has nothing to do with SQL on its own.
Okay, so we have our columns name, breed and age, and then we have the rows.
Those are the actual entries, the actual data in the table.
So we have one row here.
Blue is a Scottish fold.
She's one year old.
We have Rocket who's a Persian cat, three years old and so on.
These are all rows, their entries into this table.
But the first step is to get this table empty.
But with a structure we're telling SQL.
Okay, here's our cat's table.
It has these three different columns, the three pieces, and then once that's done, we can insert
data in.
So databases in general consist of lots of tables.
Well, I say that referring to a large application or even just a basic application you might work with.
There's going to be lots of different entities and almost every entity will have its own table.
So there might be a user's table, a friend's table, a photos table.
If we are making some sort of Instagram clone or something, a comment table and all sorts of stuff
for advertising and for tracking users and user behavior, you could have hundreds of different tables
so it can get a little crazy.
Here are some simple ish examples.
This is some of the tables that exist in the Wikipedia SQL database.
Now, this is coming from Wikipedia.
It could be out of date, but we'll see things like a user.
Every user has a name and a password and an email and a whole bunch of other things.
But then we have pages, Wikipedia pages, right?
And Wikipedia revisions because people can revise pages.
There's different sites, there's logs that are written images and files and all sorts of other things.
We don't have to worry about tags, lots of information here that is stored all in separate tables.
Now, of course, most of these tables are connected or related in some ways, like pages and users
or revisions and users.
Who's making the revision?
Well, some user is so there's some connection, but we're not worrying about that just yet.
Here's another example.
This is an old very out of date attempt at modeling the table structure of a website like Facebook.
We have things like basic information for a user sex.
If they're interested in men and women, you can tell this is out of date.
I guess that they even break it down that way.
Looking for friendship, relationship.
All right.
Basic information, contact information.
But then we have things like a profile, an account, a credit card, different events.
We have photos.
All these different entities are.
Senate with their own tables and again, lots of lines connecting them together.
So we are not starting there.
We're starting with good old cats, three columns, a couple of rows, but we have to learn how to make
a table.
And before we can create a table, we have to talk about data and the different types, the different
categories of data we can work with.