Once you get the hang of this, you’ll be joining tables left and right (pun intended).

We’ve discussed the INNER JOIN, which is similar to the IMPLICIT JOIN you’re probably used to using. Now let’s complicate things a bit! Don’t worry; it’s not that hard.

Start Joining Tables Left and Right

I bet you have already used INNER JOIN. Now imagine that the user asks you to modify the students query presented in the previous article so that all registered students, regardless of whether or not they have taken a class, are listed. But the user still wants to know which classes the students took. Although it’s very similar to the previous query, it is not simply an intersection between the tables. Nope, this time you’ll have to include all the records from the first table (Students) and the records from the second table (Classes) that have matching student names. Instead of first and second tables, let’s call them left and right tables, respectively. You now need all the records from the left table plus the ones that intersect with the right table, as depicted in Figure 1.

Figure 1: A LEFT JOIN between the Students and Classes tables

Let’s see how this translates to SQL lingo:

SELECT      STNM

            , CLNM

            , CLCN

   FROM     UMADB_CHP2.PFSTM ST

LEFT JOIN   UMADB_CHP2.PFCLM CL ON CL.CLSN = ST.STNM

;

The only difference in the statement is the LEFT JOIN instead of INNER JOIN, but the result set tells a slightly different story: a student record was omitted from the previous result set because it doesn’t have a match in the Classes table, which now appears, even though it has incomplete information. The class and course name columns (CLNM and CLCN, respectively) display a “no data available” sign (a dash, or “-“) instead of the expected contents. The dash sign indicates NULL.

Similarly, if the request were to list all the records from the Classes table (the right table) plus the matches on the Students table (the left table), you’d use a RIGHT JOIN. Visually, a RIGHT JOIN looks very much like the previous figure, but with the table roles reversed, as depicted in Figure 2.

Figure 2: A RIGHT JOIN between the Students and Classes tables

As you’d expect, the SQL statement is also very similar to the previous one:

SELECT      STNM

            , CLNM

            , CLCN

   FROM     UMADB_CHP2.PFSTM ST

RIGHT JOIN  UMADB_CHP2.PFCLM CL ON CL.CLSN = ST.STNM

;

The result will be the same as the INNER JOIN, but only because there are no records in the classes table that don’t have a match in the students table.

“Just Get Me Everything”: The FULL JOIN

So far, I’ve shown you how to select the matching records between two tables, then add to that all the records from the left table, and finally, add to that all the records from the right table. As you’ve probably guessed, there’s also a type of join that includes everything from both left and right tables: it’s the FULL OUTER JOIN, or FULL JOIN, for short:

SELECT      STNM

            , CLNM

            , CLCN

   FROM     UMADB_CHP2.PFSTM ST

   FULL JOIN      UMADB_CHP2.PFCLM CL ON CL.CLSN = ST.STNM

;

In this case, you’re selecting everything from both tables, which might not be a good idea. But who knows, maybe it can be useful in a very particular situation. This example selects students with or without classes, plus classes with or without students.

A Join Summary

Even though this joining business is not complex with two tables, it’s important to fully understand it. Database relations can get pretty complicated, and being able to join two or more tables correctly might save you some time. Figure 3 offers a summary of the join types discussed thus far:

Figure 3: A join summary

Later, I’ll revisit this topic to explain what happens when the value of columns used to link the tables (also known as key columns) is null. The next articles will return to single-table queries to explore a few SQL functions. I’ll stick to the most commonly used ones, but there are many more, with varying degrees of complexity.

Keep in mind that this was a very short and simple recap of the JOIN instructions. There’s a lot more to it than this. If you don’t feel comfortable or have doubts about this, go over the articles published by MC Press over the years using this link. Also, one of my previous books, Evolve Your RPG Coding: Move from OPM to ILE… and Beyond has a very comprehensive chapter about most of them (and a lot more basic SQL stuff).