MySQL
  Home arrow MySQL arrow Page 4 - Understanding SQL Joins
Dev Shed Forums 
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Sun Developer Network 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Mobile Linux 
App Generation ROI 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
MYSQL

Understanding SQL Joins
By: The Disenchanted Developer, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 216
    2002-08-20

    Table of Contents:
  • Understanding SQL Joins
  • Meeting The Family
  • Keeping It Simple
  • Crossed Wires
  • Finding Common Ground
  • One Step Left...
  • ...Two Steps Right
  • The Bookworm Turns
  • Up A Tree
  • A Long Goodbye

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Understanding SQL Joins - Crossed Wires


    (Page 4 of 10 )

    The examples on the previous page dealt with a single table, so the question of a join never arose. But often, using a single table returns an incomplete picture; you need to combine data from two or more tables in order to see a more accurate result.

    That's where joins come in - they allow you to combine two or more tables, and to massage the data within those tables, in a variety of different ways. For example,

    SELECT * FROM a,b;
    Here's the output:

    +----+------+----+------+ | a1 | a2 | b1 | b2 | +----+------+----+------+ | 10 | u | 10 | p | | 20 | v | 10 | p | | 30 | w | 10 | p | | 40 | x | 10 | p | | 50 | y | 10 | p | | 60 | z | 10 | p | | 10 | u | 20 | q | | 20 | v | 20 | q | | 30 | w | 20 | q | | 40 | x | 20 | q | | 50 | y | 20 | q | | 60 | z | 20 | q | +----+------+----+------+ 12 rows in set (0.00 sec)
    And that's your very first join!

    In this case, columns from both tables are combined to produce a resultset containing all possible combinations. This kind of join is referred to as a "cross join", and the number of rows in the joined table will be equal to the product of the number of rows in each of the tables used in the join. You can see this from the example above - table "a" has 6 rows, table "b" has 2 rows, and so the joined table has 6x2 = 12 rows.

    There are two basic types of SQL joins - the "inner join" and the "outer join". Inner joins are the most common - the one you just saw was an example of an inner join - and also the most symmetrical, since they require a match in each table which forms a part of the join. Rows which do not match are excluded from the final resultset.

    As you might imagine, a cross join like the one above can have huge implications for the performance of your database server. In order to illustrate, look what happens when I add a third table to the join above:

    SELECT * FROM a,b,c;
    Here's the output:

    +----+------+----+------+-----+------+ | a1 | a2 | b1 | b2 | c1 | c2 | +----+------+----+------+-----+------+ | 10 | u | 10 | p | 90 | m | | 20 | v | 10 | p | 90 | m | | 30 | w | 10 | p | 90 | m | | 40 | x | 10 | p | 90 | m | | 50 | y | 10 | p | 90 | m | | 60 | z | 10 | p | 90 | m | | 10 | u | 20 | q | 90 | m | | 20 | v | 20 | q | 90 | m | | 30 | w | 20 | q | 90 | m | | 40 | x | 20 | q | 90 | m | | 50 | y | 20 | q | 90 | m | | 60 | z | 20 | q | 90 | m | | 10 | u | 10 | p | 100 | n | | 20 | v | 10 | p | 100 | n | | 30 | w | 10 | p | 100 | n | | 40 | x | 10 | p | 100 | n | | 50 | y | 10 | p | 100 | n | | 60 | z | 10 | p | 100 | n | | 10 | u | 20 | q | 100 | n | | 20 | v | 20 | q | 100 | n | | 30 | w | 20 | q | 100 | n | | 40 | x | 20 | q | 100 | n | | 50 | y | 20 | q | 100 | n | | 60 | z | 20 | q | 100 | n | | 10 | u | 10 | p | 110 | o | | 20 | v | 10 | p | 110 | o | | 30 | w | 10 | p | 110 | o | | 40 | x | 10 | p | 110 | o | | 50 | y | 10 | p | 110 | o | | 60 | z | 10 | p | 110 | o | | 10 | u | 20 | q | 110 | o | | 20 | v | 20 | q | 110 | o | | 30 | w | 20 | q | 110 | o | | 40 | x | 20 | q | 110 | o | | 50 | y | 20 | q | 110 | o | | 60 | z | 20 | q | 110 | o | +----+------+----+------+-----+------+ 36 rows in set (0.05 sec)
    Though each of the tables used in the join contains less than ten records each, the final joined result contains 6x2x3=36 records. This might not seem like a big deal when all you're dealing with are three tables containing a total of 11 records, but imagine what would happen if you had three tables, each containing 100 records, and you decided to cross join them...

    More MySQL Articles
    More By The Disenchanted Developer, (c) Melonfire


     

       

    MYSQL ARTICLES

    - MySQL Server Tuning Tips and Tricks
    - MySQL Query Optimizations and Schema Design
    - MySQL Benchmarking Tools and Utilities
    - MySQL Benchmarking Concepts and Strategies
    - Take Some Load off MySQL with MemCached
    - MySQL Table Prefix Changer Tool in PHP
    - Using the SIGNAL Statement for Error Handling
    - Error Handling Examples
    - Error Handling
    - Completing a Search Engine with MySQL and PH...
    - Paginating Result Sets for a Search Engine B...
    - Building a Search Engine with MySQL and PHP 5
    - Using Boolean Operators for Full Text and Bo...
    - PHP, MySQL and the PEAR Database
    - Working with PHP and MySQL





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 3 hosted by Hostway
    Stay green...Green IT