Data held in SQL tables should be normalised - in other words, held in neat multiple tables with complete rows, only one piece of logical data per cell, and with information not being repeated in multiple places. (The "why" is off topic for this article, but it basically helps data maintenance and integrity no end).

Multiple normalised tables can be linked together within select commands and this linking is known as joining; when you specifiy a join, you also specify a criteria to tell MySQL how to make the connection, and that's typically done using a key. Let's see a simple example.

Two tables - bdg containing buildings ....


... and res containing residents living there.


When I connect (join) those tables together, I wish to do so by linking the "bid"s - and the syntax I use is:

select * from bdg, res where bdg.bid = res.bid ;

You'll notice that I DON'T use the word join (I could ... but that's another story). Here's my output:


Which is good - in other words, it's what I expected. BUT ... it might be that I want to see at least one row on my report for each of the incoming rows in (say) my building table - to alert me to buildings that don't match any resident records at all. Than can be done using a LEFT JOIN in my select:

select * from bdg left join res on bdg.bid = res.bid ;
    
which gives:



Regular joins and left joins can be extended to three and more tables - the principle is easy but the syntax less so; let's say that we had a third table called dom containing the names of any internet domains registered to each individual:


A regular join on the (now) three tables is straightforward:

select * from bdg, res, dom where bdg.bid = res.bid and res.rid = dom.rid;

and gives the following result:


The syntax for a three way LEFT JOIN is more complex (and thus the inspiration for this article):

select * from (bdg left join res on bdg.bid = res.bid) left join dom on res.rid = dom.rid;

and gives the following result:


Notice that our report now includes orphan records at both join levels - entries in the bdg table that have no corresponding entry in the res table, and entries in the res table that have no corresponding entry in the dom table.


Should we wish to report on orphan records only, we can do so by testing for NULL fields in fields that may not otherwise have a null value.

Example - looking for all incomplete records:

select * from (bdg left join res on bdg.bid = res.bid) left join dom on res.rid = dom.rid where dom.rid is NULL;


Example - looking for all buildings with no residents:

select * from (bdg left join res on bdg.bid = res.bid) left join dom on res.rid = dom.rid where res.rid is NULL;


(Hey - you really don't need to join in the domain table for this)

Example - looking for all residents with no domains:

select * from (bdg left join res on bdg.bid = res.bid) left join dom on res.rid = dom.rid where dom.rid is NULL and res.rid is not NULL;



Here's a complete set of the commands I used to set up this example - you're welcome to cut and paste it for your own testing and experimentation:



See also More (My)SQL commands

Please note that articles in this section of our web site were current and correct to the best of our ability when published, but by the nature of our business may go out of date quite quickly. The quoting of a price, contract term or any other information in this area of our website is NOT an offer to supply now on those terms - please check back via our main web site

MySQL - General
  [2053] - ()
  [2085] - ()
  [2134] - ()
  [2240] - ()
  [2426] - ()
  [2559] - ()
  [2561] - ()
  [2567] - ()
  [2861] - ()
  [3361] - ()

More MySQL commands
  [158] - ()
  [159] - ()
  [279] - ()
  [449] - ()
  [494] - ()
  [502] - ()
  [513] - ()
  [515] - ()
  [517] - ()
  [567] - ()
  [572] - ()
  [581] - ()
  [591] - ()
  [673] - ()
  [1213] - ()
  [1235] - ()
  [1331] - ()
  [1574] - ()
  [1735] - ()
  [1904] - ()
  [2110] - ()
  [2259] - ()
  [2448] - ()
  [2643] - ()
  [2644] - ()
  [2645] - ()
  [2647] - ()
  [3061] - ()
  [3270] - ()
  [4481] - ()

SQL Primer as Used in MySQL
  [158] - ()
  [270] - ()
  [494] - ()
  [502] - ()
  [515] - ()
  [591] - ()
  [2240] - ()
  [3060] - ()
  [3061] - ()
  [4007] - ()

resource index - MySQL
Solutions centre home page

You'll find shorter technical items at The Horse's Mouth and delegate's questions answered at the Opentalk forum.

At Well House Consultants, we provide training courses on subjects such as Ruby, Lua, Perl, Python, Linux, C, C++, Tcl/Tk, Tomcat, PHP and MySQL. We're asked (and answer) many questions, and answers to those which are of general interest are published in this area of our site.