SQL roadblock beginners might run into (part 1)

The `INNER JOIN` statement

·

3 min read

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.