Photo by Rubaitul Azad on Unsplash
SQL roadblock beginners might run into (part 1)
The `INNER JOIN` statement
Hey guys!
This is a follow-up to my last blog post. You can check it out here. I do appreciate the support thus far.
As you must know based on my previous blog, I just started learning SQL. This would be a series of roadblocks and challenges SQL beginners might run into and it would be based on issues I've found challenging or confusing. Throughout this series, I would be taking the approach of a programmer cognizant of basic programming concepts. If you are not familiar with any programming concepts or if SQL is your first ever language (which I think is pretty interesting) you could also follow along provided you've been doing your personal study.
So, lets get started
The INNER JOIN
statement
When I was first trying to apply this concept to a few exercises, it wasn't really clicking for me. But with more research and study, I'm going to try and explain to you what really goes on with the INNER JOIN
statement. So bear with me
For INNER JOIN
to be well understood, you have to understand primary keys and foreign keys.
A foreign key in one table is usually a primary key in another table.
We usually use INNER JOIN
to join one table to another table in the same database. In a lot of cases, we would want to use data stored in an entirely different table in the same database. This will only work if the primary key in one table is at least a foreign key in the other table.
Moreover, INNER JOIN
only joins tables with specified matching entities. If supposed entities don't match, they won't get displayed. Think of it like Sets. We would only be interested in the intersection of 2 or multiple sets only (Can there be an intersection of more than 3 sets?? Let me know in the comments below)
So lets say we had a Store database and we had a table called customers
that had fields of CustomerName
, cutomerid
, state
and table called orders
that had customerid
, orderid
, and price
. If we wanted to get the customers that had ordered from New York, Maine, and Texas, it would look something like this:
SELECT o.customerid, cust.state FROM customers as cust
INNER JOIN orders AS o ON cust.customerid = o.customerid
AND cust.state in ('TX', 'MN', 'NY') -- the entities could also be 'Texas', 'Maine', 'New York' respectively
This already looks like object-oriented programming in some other programming languages and the concept here is similar. So I'll be explaining each command line by line.
SELECT o.customerid, cust.state FROM customers as cust
You probably should already know what SELECT
does. But the problem lies with o.customerid
and cust.state
.
In OOP we usually declare the class and the methods before assigning objects to that class and using the methods but in SQL its like we are already using the attributes before anything has been declared
SQL is weird...
So FROM customers AS cust
uses cust
as a variable to represent customers
. So cust.state
is similar to customers.state
. That is the state
field from the customer
table.
But what about o.customerid
??
That's where the second line comes in...
INNER JOIN orders AS o ON cust.customerid = o.customerid
This line joins the the orders
table and uses o
to represent it. So o
in o.customerid
is the customerid
field in orders.
Then we link the two tables using the customerid
since its available in both tables and they are both primary key and foreign key.
There is no WHERE
clause for joins in general since the ON
keyword behaves like that already
Sounds good?
If you've been learning SQL for a while the last line shouldn't be a problem.
Final thoughts
I really do hope this helps someone. If you have any questions please do leave your questions in the comments. All type of criticism is allowed. Follow for more of these blogs.