Samuel Tucker

Samuel Tucker


Understanding SQL Joins

In this tutorial, you'll learn about SQL JOINs, the different types (LEFT, RIGHT, and INNER Join), and when to use them so you can write better queries.

SQL Joins – LEFT Join, RIGHT Join, and INNER Join Explained

SQL is a programming language we use to interact with relational databases. SQL databases contain tables, which contain rows of data. These tables usually contain similar or related data.

In an office management web application database, you would have tables for employees, their departments, their managers, the projects they work on, and so on depending on the structure of your application.

In the employees table, you would find data like the employee ID, name, salary, department ID (used to link the employee to the department), and other fields that match your needs. The other tables would also contain data for their specific entities.

What Are Joins?

If you ever need to bring multiple tables in your database together to access the data, you use a JOIN.

Joins let you fetch data that is scattered across tables. For example, using the database tables that we'll create in a moment, we'll be able to get all the details of an employee, along with their manager name, and department they're working in by using a join.

A join lets you use a single query to achieve this. You use a join because you can only get this data by bringing data from the employees table, departments table, and projects table together. In simple terms, you would be JOIN-ing these tables together.

To perform a join, you use the JOIN keyword. And we'll see how it works in this tutorial.


To continue with this tutorial, you should know the basics of insertion and retrieval operations with SQL.

Also, you can setup a demo database that we'll use for this article. The database should have tables like this:

CREATE TABLE employees (
    id int,
    emp_name varchar(100),
    salary int,
    dept_id int,
    manager_id int

INSERT INTO employees 
VALUES (1, 'Idris', 1000, 1, 1), (2, 'Aweda', 2000, 2, 2), (3, 'Zubair', 3000, 3, 2), (4, 'Young', 4000, 3, 3), (5, 'Babu', 5000, 1, 3), (6, 'John', 1000, 8, 1);

CREATE TABLE departments (
    id int,
    dept_name varchar(100)

INSERT INTO departments
VALUES (1, 'Engineering'), (2, 'Product'), (3, 'Marketing'), (4, 'Support');

CREATE TABLE managers (
    id int,
    manager_name varchar(100),
    dept_id int

INSERT INTO managers
VALUES (1, 'Doe', 1), (2, 'Jane', 2), (3, 'May', 4);

CREATE TABLE projects (
    id int,
    project_name varchar(100),
    emp_id int

INSERT INTO projects
VALUES (1, 'Fintech App', 1), (1, 'Fintech App', 5), (1, 'Fintech App', 6), (2, 'Cooking Website', 1), (2, 'Cooking Website', 2);

SQL to quickly setup the tables used in the article

How to Use an Inner Join in SQL

There are many types of joins in SQL, and each one has a different purpose.

The inner join is the most basic type of join. It is so basic that sometimes, you can omit the JOIN keyword and still perform an inner join.

For example, say you want to fetch the name of all employees in the organanization, along with the name of their departments. In a situation like this, you need data from both the employees table and the departments table. A simple join like this would do:

SELECT e.emp_name, d.dept_name 
FROM employees e, departments d 
WHERE e.dept_id =;

A very simple JOIN query

So how does this actually work? To start with, take a look at the FROM part of the query:

FROM employees e, departments d

Here, data is being fetched from more than one table, and each table is aliased. The alias is very useful for scenarios where both tables have similarly named fields,  like the id field both tables have in this case. You would be able to access the different fields easily using the short alias created.

Next, in the SELECT part of the query, we also specify the columns we want (and we use the alias to tell which table each value comes from):  

SELECT e.emp_name, d.dept_name

And finally, to ensure only correct values are matched to each other, the WHERE part of the query specifies the conditions that have to be met for the data to be joined.

WHERE e.dept_id =;

So for the first employee, the dept_id is 1, so we fetch the department with id = 1, and it's name is returned. This happens for as many rows as there are in the employees table.

The result of the query looks like this:


Result of JOIN query

Here, notice that the number of employees returned is smaller than the number of employees that actually exist. This is because when you use an INNER JOIN, you only get records that exist in both tables.

That is, the employee with id = 6 that was not returned has a dept_it = 8. Now, this department isn't in the departments table, so it wasn't returned.

Another way to achieve this same result would be to actually spell out the JOIN like this:

SELECT e.emp_name, d.dept_name
FROM employees e
JOIN departments d
ON (e.dept_id =;

Or use the INNER JOIN like this:

SELECT e.emp_name, d.dept_name
FROM employees e
INNER JOIN departments d
ON (e.dept_id =;

These queries return exactly the same result as the first one. But they are more readable as they're explicit.

In these queries, you're selecting from the employees table, then joining the departments table to the result. The ON in the query is used to specify the conditions on which to JOIN. It's the same as the WHERE condition in the first query.


In real applications, you use an INNER JOIN when only records that exist in both tables matter.

For example, in an inventory management application, you could have a table for sales, and another for products. Now, the sales table will contain product_id (a reference to the sold product), along with other details like sold_at (when the product was sold) and maybe customer details.

The products table, on the other hand, will have the name, price, and maybe the quantity of every product.

Now say it's end of the week and you need to do a sales report. You would need to fetch all sales records, along with the product name and price to display on a dashboard or export as a CSV of some sort.

To do this, you would use an INNER JOIN of the products table on the sales table, because you do not care about products that were not sold – you only want to see every sale that was made, and the name and price of the product that was sold. Every other product will be exempted from this report.

How to Use a Left Join in SQL

In another scenario, you might want to fetch all the employee names and their department names, but this time without leaving any employee or department name out. Here, you'd you use a LEFT JOIN.

In a LEFT JOIN, every record from the table on the left, the base table, will be returned. Then values from the right table, the table being joined, will be added where they exist.

The LEFT JOIN is also known as LEFT OUTER JOIN and you can use them interchangeably.

So to fetch all employee and department names, you can modify the previous query to use LEFT JOIN, like this:

SELECT e.emp_name, d.dept_name
FROM employees e
LEFT JOIN departments d
ON (e.dept_id =;

The result of this query looks like this now:


Result of LEFT JOIN

Now, employee with id = 6 and dept_id = 8 is returned, with the department name being set as NULL because there is no department with id = 8.


In real applications, you use a LEFT JOIN when there's a primary, always existing entity that can be related to another entity that doesn't always exist.

An easy use case would be in a multi-vendor ecommerce application where after a user signs up, they can set up a store and add products to the store.

A user, on signing up, doesn't automatically have a store until they create it. So if you try to view all users, with their store details, you would use a LEFT JOIN of the stores table on the users table. This is because every record in the users table is important, store or no store.

When the user has a store set up, the store details are returned, and if otherwise, NULL is returned. But, you wouldn't be losing any existing data.

How to Use a Right Join in SQL

The RIGHT JOIN works like the opposite of the LEFT JOIN. In a RIGHT JOIN, every record from the table on the right, the table being joined, will be returned. Then values from the left table, the base table, will be added where they exist.

The RIGHT JOIN is also known as the RIGHT OUTER JOIN and you can use them interchangeably.

An example would be to modify the previous query to use a RIGHT JOIN instead of a LEFT JOIN, like this:

SELECT e.emp_name, d.dept_name
FROM employees e
RIGHT JOIN departments d
ON (e.dept_id =;

Now, your result looks like this:


Result of RIGHT JOIN

Now, every department in the departments table was returned. And employees in those departments were returned too. For the last row, there is no employee with dept_id = 4, which is why the NULL value gets returned.


The RIGHT JOIN works exactly as the LEFT JOIN works in real applications. The difference between them comes from the level of importance of the tables to be joined.

The LEFT JOIN is more commonly used because you very likely will write your query from left to right, listing tables in that order of importance too. Otherwise, the RIGHT JOIN works exactly as the LEFT JOIN.

How to Combine JOINS in SQL

So far, we've only joined one table to another. But, you can actually join as many tables as you like by using any or all of these joins together as you like.

For example, say you want to fetch the names of all employees, with their department names, manager names, and projects names. You would have to join the employees table to the departments table, the managers table, and the projects table. You can achieve this using this query:

SELECT e.emp_name, d.dept_name, m.manager_name, p.project_name
FROM employees e
LEFT JOIN departments d
ON (e.dept_id =
LEFT JOIN managers m
ON (e.manager_id =
LEFT JOIN projects p
ON ( = p.emp_id);

In this query, start from the employees table as a base table. Then you LEFT JOIN the departments table. You also LEFT JOIN the managers table, and finally, the projects table.

The result of this query will look like this:


Result of general JOIN query

The reason for using a LEFT JOIN here is because you have to fetch ALL employees. You could use an INNER JOIN in place of the LEFT JOIN in the managers table because all employees have a manager_id that actually exists in the managers table. But to be safe, you can just use the LEFT JOIN.

How to Use a Cross Join in SQL

This is also known as a CARTESIAN JOIN. It returns every record from both tables in a multiplication-like manner. It returns every possible combination of rows from both tables. It doesn't need a JOIN condition like the other JOINs.

For example, if you do a CROSS JOIN between tables employees and departments, your result will look like this:

SELECT e.emp_name, d.dept_name
FROM employees e
CROSS JOIN departments d;

CROSS JOIN employees and departments table.Screenshot-2023-01-07-at-20.19.24CROSS JOIN of employees and departments tables.

Here you have 24 rows, which is a product of the number of rows in the employees table, 6, and the number of rows in the departments table, 4. The records were returned so that for every record in the employees table, it is mapped to a record in the departments table.


A common use case of CROSS JOIN would be in an ecommerce application where it is possible to have size or color variations of all products. If you ever need to fetch a list of all products in different sizes, like this:


Result of a basic CROSS JOIN

This result was gotten from CROSS JOINing a sizes table that contains an id for each size, a string size that can be either 'Small', 'Medium', or 'Large' and another field called ratio to affect how this size affects the product price. So, for every product, it is mapped to a size, and the price is calculated.

  ROUND(p.price * s.ratio, 2) as price, 
FROM products p 
CROSS JOIN sizes s;

How to Use a Self Join in SQL

As the name implies, is when you try to join a table to itself. There is no self JOIN keyword.

Take this new categories table, for example. This table contains both main categories and sub-categories. If you ever have to fetch the categories and their sub-categories, you can use a SELF JOIN.

CREATE TABLE categories (
    id int,
    cat_name varchar(100),
    parent_category_id int DEFAULT NULL

INSERT INTO categories 
VALUES (1, 'Ladies', NULL), (2, 'Mens', NULL), (3, 'Lingeries', 1), (4, 'Shoes', 2);

Create categories table.

SELECT cat.cat_name, parent_cat.cat_name AS parent 
FROM categories cat
JOIN categories parent_cat 
ON cat.parent_category_id =;

Self JOIN query

Here, see how the table was referenced twice. Be careful with the alias as it's important in differentiating both instances. The result of this query looks like this:


Result of simple Self JOIN on categories table


In many applications, you find hierarchical data stored in a single table. Like the category and sub-category as shown in the previous example. Or as in employee and manager, because they're both employees of the company.

In case of the latter, the table will have fields such as id, name, manager_id (this is basically the id of another employee). Let's say you want to write a query where you have to fetch a list of managers and the number of their employees. Given that these managers are also employees, you only have one table to fetch from, the employees table. To do this fetch, do a SELF JOIN of the employees table on the employees table like this:

SELECT AS supervisor, COUNT( AS number_of_employees
FROM employee e1
JOIN employee e2
ON e1.manager_id =

This would correctly return the managers and the number of employees working under them.


I hope you now understand SQL JOINs, the different types, and when to use them so you can write better queries.

All the JOINs here work with MySQL. There are other JOINs like FULL OUTER JOIN and NATURAL JOIN that we didn't discuss, but you can look into them yourself if you like.

If you have any questions or relevant advice, please get in touch with me to share them.

Original article source at

#sql #database 

What is GEEK

Buddha Community

Understanding SQL Joins
Cayla  Erdman

Cayla Erdman


Introduction to Structured Query Language SQL pdf

SQL stands for Structured Query Language. SQL is a scripting language expected to store, control, and inquiry information put away in social databases. The main manifestation of SQL showed up in 1974, when a gathering in IBM built up the principal model of a social database. The primary business social database was discharged by Relational Software later turning out to be Oracle.

Models for SQL exist. In any case, the SQL that can be utilized on every last one of the major RDBMS today is in various flavors. This is because of two reasons:

1. The SQL order standard is genuinely intricate, and it isn’t handy to actualize the whole standard.

2. Every database seller needs an approach to separate its item from others.

Right now, contrasts are noted where fitting.

#programming books #beginning sql pdf #commands sql #download free sql full book pdf #introduction to sql pdf #introduction to sql ppt #introduction to sql #practical sql pdf #sql commands pdf with examples free download #sql commands #sql free bool download #sql guide #sql language #sql pdf #sql ppt #sql programming language #sql tutorial for beginners #sql tutorial pdf #sql #structured query language pdf #structured query language ppt #structured query language

Karlee  Will

Karlee Will


Your Ultimate Guide to SQL Join: CROSS JOIN

CROSS JOIN is in the spotlight. This article finishes our small series of SQL JOIN-related publications.

SQL Server CROSS JOIN is the simplest of all joins. It implements a combination of 2 tables without a join condition. If you have 5 rows in one table and 3 rows in another, you get 15 combinations. Another definition is a Cartesian Product.

Now, why would you want to combine tables without a join condition? Hang on a bit because we are getting there. First, let’s refer to the syntax.

#sql server #cross join #inner join #outer join #sql join #sql

Karlee  Will

Karlee Will


Your Ultimate Guide to SQL Joins: OUTER JOIN

Outer join is at the center stage today. And this is part 2 of your ultimate guide to SQL joins. If you missed part 1, here’s the link.

By the looks of it, outer is the opposite of inner. However, if you consider the outer join this way, you’ll be confused. To top that, you don’t have to include the word outer in your syntax explicitly. It’s optional!

But before we dive in, let’s discuss nulls concerning outer joins.

Nulls and OUTER JOIN

When you join 2 tables, one of the values from either table can be null. For INNER JOINs, records with nulls won’t match, and they will be discarded and won’t appear in the result set. If you want to get the records that don’t match, your only option is OUTER JOIN.

Going back to antonyms, isn’t that the opposite of INNER JOINs? Not entirely, as you will see in the next section.

#sql server #inner join #outer join #sql join #sql

Karlee  Will

Karlee Will


Your Ultimate Guide to SQL Join: INNER JOIN

Inner join, outer join, cross join? What gives?

It’s a valid question. I once saw a Visual Basic code with T-SQL codes embedded in it. The VB code retrieves table records with multiple SELECT statements, one SELECT * per table. Then, it combines multiple result sets into a record set. Absurd?

To the young developers who did it, it was not. But when they asked me to evaluate why the system was slow, that issue was the first to catch my attention. That’s right. They never heard of SQL joins. In fairness to them, they were honest and open to suggestions.

How do you describe SQL joins? Perhaps, you remember one song – Imagine by John Lennon:

You may say I’m a dreamer, but I’m not the only one.

I hope someday you’ll join us, and the world will be as one.

#sql server #inner join #sql join #t-sql #sql

Cayla  Erdman

Cayla Erdman


Welcome Back the T-SQL Debugger with SQL Complete – SQL Debugger

When you develop large chunks of T-SQL code with the help of the SQL Server Management Studio tool, it is essential to test the “Live” behavior of your code by making sure that each small piece of code works fine and being able to allocate any error message that may cause a failure within that code.

The easiest way to perform that would be to use the T-SQL debugger feature, which used to be built-in over the SQL Server Management Studio tool. But since the T-SQL debugger feature was removed completely from SQL Server Management Studio 18 and later editions, we need a replacement for that feature. This is because we cannot keep using the old versions of SSMS just to support the T-SQL Debugger feature without “enjoying” the new features and bug fixes that are released in the new SSMS versions.

If you plan to wait for SSMS to bring back the T-SQL Debugger feature, vote in the Put Debugger back into SSMS 18 to ask Microsoft to reintroduce it.

As for me, I searched for an alternative tool for a T-SQL Debugger SSMS built-in feature and found that Devart company rolled out a new T-SQL Debugger feature to version 6.4 of SQL – Complete tool. SQL Complete is an add-in for Visual Studio and SSMS that offers scripts autocompletion capabilities, which help develop and debug your SQL database project.

The SQL Debugger feature of SQL Complete allows you to check the execution of your scripts, procedures, functions, and triggers step by step by adding breakpoints to the lines where you plan to start, suspend, evaluate, step through, and then to continue the execution of your script.

You can download SQL Complete from the dbForge Download page and install it on your machine using a straight-forward installation wizard. The wizard will ask you to specify the installation path for the SQL Complete tool and the versions of SSMS and Visual Studio that you plan to install the SQL Complete on, as an add-in, from the versions that are installed on your machine, as shown below:

Once SQL Complete is fully installed on your machine, the dbForge SQL Complete installation wizard will notify you of whether the installation was completed successfully or the wizard faced any specific issue that you can troubleshoot and fix easily. If there are no issues, the wizard will provide you with an option to open the SSMS tool and start using the SQL Complete tool, as displayed below:

When you open SSMS, you will see a new “Debug” tools menu, under which you can navigate the SQL Debugger feature options. Besides, you will see a list of icons that will be used to control the debug mode of the T-SQL query at the leftmost side of the SSMS tool. If you cannot see the list, you can go to View -> Toolbars -> Debugger to make these icons visible.

During the debugging session, the SQL Debugger icons will be as follows:

The functionality of these icons within the SQL Debugger can be summarized as:

  • Adding Breakpoints to control the execution pause of the T-SQL script at a specific statement allows you to check the debugging information of the T-SQL statements such as the values for the parameters and the variables.
  • Step Into is “navigate” through the script statements one by one, allowing you to check how each statement behaves.
  • Step Over is “execute” a specific stored procedure if you are sure that it contains no error.
  • Step Out is “return” from the stored procedure, function, or trigger to the main debugging window.
  • Continue executing the script until reaching the next breakpoint.
  • Stop Debugging is “terminate” the debugging session.
  • Restart “stop and start” the current debugging session.

#sql server #sql #sql debugger #sql server #sql server stored procedure #ssms #t-sql queries