I welcome the module to databases. You're in less than one database relationships, and this is lesson 1.2
and this. Listen, we're gonna take a look at what the table structure is and what it represents in databases. We'll do that with an introductory look at how to think of database tables when you knew the sequel programming or databases. In general,
it's It's easier to think of database tables as spreadsheets, the represent concepts in that database,
and we'll talk about why they get broken out this way later.
It's easy when you're new, to think that why don't I just merge all this stuff onto one table? But that actually turns into quite a pain, too,
before maintenance on and develop further as the database size increases, usually when it's a small database application and doesn't have a lot of responsibilities as faras gathering and tracking data, having even just one big database table works. But if you start trying thio,
make it a more flexible application by making it watch different types of data.
You'll start to run into a lot of trouble if you try to keep things on a very limited or even one super table,
and we'll look at that later. But first, let's look at what tables are and what they represent, and a good way to look at that. When your new is that. Hey, tables represents spreadsheets
and spreadsheets. The spreadsheets represents specific concepts. Okay, so, for example, we haven't employees spread sheet,
a state spreadsheet,
this city spread sheet
and a salary spreadsheet. If we take a look at the employee spreadsheet that will see that there are two records, which is just a minimal example, there could easily be hundreds or thousands of records on any given ah, database table, depending on what type of table and what type database you're dealing with. But in this one, we only have two.
We have two entries a kid, Parker and John Smith.
We could see that kid Parker has a primary idea of one
and a state i d. Of two. And how do we know that's an I. D. Well, we know that
there is no state that is known, is it too?
So it's a safe assumption
that there's a state table with an idea of table. Oh, I mean with it. I'm sorry with an idea of two out there
and in this employee table. The state, too,
is a foreign key, which means that in another table it's a primary key.
So let's say that we're writing a very simple query, and we wanted to know what state employees were in. And let's speed even more specific. We want to know what state Kit Parker is in. So this query would reach this table slash spreadsheet
fine kid Parker by the idea of one
and say, OK, kid, Parker's in state. To what state is that? Well, I have to go to the state table to find out.
So we traveled to the state table. Let me say, Okay, I mother stayed table. I need the state with the idea of two.
Okay, two. Is California with a coat of C A.
So when we respond when I when I quit the response to the user to say Kid belongs to California and the code for that state is C A.
Okay, that was an easy example.
Now let's let's go on to another example that uses a state table.
I say that we were looking at a city table
and we see a city of Phoenix
and a state idea of one.
And we're say we write a simple query. You say I want to know what state
So the quicker we would go to the city table
slash spreadsheet you wouldn't say. Okay, what state does Phoenix belong to? Okay, I have a state column with the state of 11 is not a state. So I need to go to the state table
and ah, we see that the idea of one in the state table represents Arizona.
And we can answer that question by saying OK,
by using these to spread sheets together,
I can tell the Phoenix is in Arizona
and let's do one more example.
Now we have probably the most popular table in any database the salary table, slash spreadsheet. So we're looking here and we're saying, all right,
we got a salary type of hourly. That's 15.
Who belongs to that.
Okay, that looks like that's ah.
and then go back to the employees table.
employees idea of one kid, Parker, because then say Kit Parker gets paid $15 an hour,
and we were able to answer that question using these two tables or these spreadsheets.
And just to recap on this spreadsheet or tables, tables or spreadsheets.
Tables in the database are very similar to spreadsheets,
and usually when you're dealing with a
pretty reasonable database, you're gonna see that these tables slash spreadsheets represents specific concepts. On that, you look up answers to questions
within any program by connecting the ideas off the spreadsheets last tables together,
and that closes this lesson. I hope you enjoyed it, and I'll see you in the next lesson.