Académique Documents
Professionnel Documents
Culture Documents
www.sqlservercentral.com/articles/T-S
http://www.sqlservercentral.com/articles/T-SQL/67941/
Printed 2011/02/25 10:56PM
sqlservercentral.com/articles//Printable
1/11
25/02/2011
www.sqlservercentral.com/articles/T-S
Figure 1: Combining objects from different sets Once you understand the analogy, things will start to make sense. Consider that the 2 sets in Figure 1 are tables and the numbers we see are the keys we will use to join the tables. So in each set, instead of representing the whole records, we are only seeing the key fields from each table. The result set of this combination will be determined by the type of join we consider, and this is the topic I will show now. To illustrate our examples, consider we have 2 tables, shown below:
Table1
key1 3 4 6 7 8 field1 Erik John Mark Peter Harry field2 8 3 3 6 0 key2 1 4 7 8 9 key3 6 4 1 5 2
Table2
key2 1 2 4 5 6 9 0 field1 New York Sao Paulo Paris London Rome Madrid Bangalore field2 A B C C C C D field3 N N Y Y Y Y N
The script to create and populate those tables are available as one attached file (SQLServerCentral.com_JOIN.sql) in the Resources section below.
sqlservercentral.com/articles//Printable 2/11
25/02/2011
www.sqlservercentral.com/articles/T-S
You will notice this script does not fully implement referential integrity. I intentionally left the tables without foreign keys to better explain the functionality of the different types of joins. But I did so for didactical purposes only. Foreign keys are extremely useful to guarantee data consistency and they should not be left out of any real-world database. Well, now we are ready to go. Let's check the types of joins we can use in T-SQL, the correspondent syntax and the result set that each one will generate.
Figure 2: Representing the INNER JOIN Now check the syntax to combine the data from Table1 and Table2 using a INNER JOIN.
SELECT t1.key1, t1.field1 as Name, t1.key2 as T1Key, t2.key2 as T2Key, t2.field1 as City FROM Table1 t1 INNER JOIN Table2 t2 ON t1.key2 = t2.key2;
The result set of this statement will be: key1 3 4 8 Name Erik John Harry T1Key 1 4 9 T2Key 1 4 9 City New York Paris Madrid
Notice it returned only the data from records which have the same value for key2 on both Table1 and Table2. Opposed to the INNER JOIN, there is also the OUTER JOIN. There are 3 types of OUTER JOINs, named full, left and right. We will look at each one in detail below.
sqlservercentral.com/articles//Printable
3/11
25/02/2011
www.sqlservercentral.com/articles/T-S
Figure 3: Representing the FULL JOIN The syntax is almost exactly the same we saw before.
SELECT t1.key1, t1.field1 as Name, t1.key2 as T1Key, t2.key2 as T2Key, t2.field1 as City FROM Table1 t1 FULL JOIN Table2 t2 ON t1.key2 = t2.key2 ;
The result set of this statement will be: key1 3 4 6 7 8 null null null null Name Erik John Mark Peter Harry null null null null T1Key 1 4 7 8 9 null null null null T2Key 1 4 null null 9 2 5 6 0 City New York Paris null null Madrid Sao Paulo London Rome Bangalore
The FULL JOIN returns all records from Table1 and Table2, without duplicating data.
25/02/2011
www.sqlservercentral.com/articles/T-S
The result set of this statement will be: key1 3 4 6 7 8 Name Erik John Mark Peter Harry T1Key 1 4 7 8 9 T2Key 1 4 null null 9 City New York Paris null null Madrid
The third and forth records (key1 equals to 6 and 7) show NULL values on the last fields because there is no information to be brought from the second table. This means we have a value in field key2 in Table1 with no correspondent value in Table2. We could have avoided this "data inconsistency" in case we had a foreign key on field key2 in Table1.
sqlservercentral.com/articles//Printable
5/11
25/02/2011
www.sqlservercentral.com/articles/T-S
Figure 5: Representing the RIGHT JOIN As you can see, syntax is very similar.
SELECT t1.key1, t1.field1 as Name, t1.key2 as T1Key, t2.key2 as T2Key, t2.field1 as City FROM Table1 t1 RIGHT JOIN Table2 t2 ON t1.key2 = t2.key2 ;
The result set of this statement will be: key1 null 3 null 4 null null 8 Name null Erik null John null null Harry T1Key null 1 null 4 null null 9 T2Key 0 1 2 4 5 6 9 City Bangalore New York Sao Paulo Paris London Rome Madrid
Observe now that records with key1 equal to 6 and 7 no longer appear in the result set. This is because they have no correspondent record in the right table. There are 4 records showing NULL values on the first fields, because they are not available in the left table.
25/02/2011
www.sqlservercentral.com/articles/T-S
As Table1 has 5 records and Table2 has another 7, the output for this query will have 35 records (5 x 7). Please check the attached file (SQLServerCentral.com_JOIN_CrossJoin.rpt). Quite honestly, I don't remember at this very moment not a single real-life situation that I do need to generate a Cartesian product of two tables. But whenever you need, CROSS JOIN is there, anyway. Besides, you should be concerned about performance. Say you accidentally run in your production server a query with a CROSS JOIN over two tables with 1 million records. This is surely something that will give you a headache. Probably your server will start showing performance problems, as your query might run for some time consuming a considerable amount of the server resources.
And this is the output to this query. key1 3 4 6 7 8 Name Erik John Mark Peter Harry field2 8 3 3 8 0 Boss Harry Erik Erik Harry null
In this example, the last record shows that Harry has no boss, or in other words, he is the #1 in the company's hierarchy.
25/02/2011
www.sqlservercentral.com/articles/T-S
Figure 6: Non-matching records from Table1. We can write a LEFT JOIN for this query, for instance:
SELECT t1.key1, t1.field1 as Name, t1.key2 as T1Key, t2.key2 as T2Key, t2.field1 as City FROM Table1 t1 LEFT JOIN Table2 t2 ON t1.key2 = t2.key2 WHERE t2.key2 IS NULL;
And, finally, the result set will be: key1 6 7 Name Mark Peter T1Key 7 8 T2Key null null City null null
When we do this kind of query, we have to pay attention to which field we pick for the WHERE clause. We must use a field that does not allow NULL values. Otherwise the result set may include unwanted records. That's why I suggested to use the second table's key. More specifically, its primary key. Since primary keys don't accept NULL values, they will assure our result set will be just what we needed.
sqlservercentral.com/articles//Printable
8/11
25/02/2011
www.sqlservercentral.com/articles/T-S
Non-equal Comparisons
sqlservercentral.com/articles//Printable 9/11
25/02/2011
www.sqlservercentral.com/articles/T-S
When we write SQL statements using the JOIN operator, we usually compare if one field in one table is equal to another field in the other table. But this is not the mandatory syntax. We could use any logical operator, like different than (<>), greater than (>), less than (<) and so on. Although this fancy stuff might give you the impression that SQL gives so much power, I feel this is more like a cosmetic feature. Consider this example. See Table 1 above , where we have 5 records. Now let's consider the following SQL statement.
SELECT t1.key1, t1.field1 as Name, t1.key2 as T1Key, t2.key2 as T2Key, t2.field1 as City FROM Table1 t1 INNER JOIN Table2 t2 ON t1.key2 <= t2.key2 WHERE t1.key1 = 3 ;
Notice this uses an inner join and we are specifically picking one single record from Table1, the one where key1 is equal to 3. The only problem is that there are 6 records and Table2 that satisfy the join condition. Take a look in the output to this query. key1 3 3 3 3 3 3 Name Erik Erik Erik Erik Erik Erik T1Key 1 1 1 1 1 1 T2Key 1 2 4 5 6 9 City New York Sao Paulo Paris London Rome Madrid
The problem with non-equal joins is that they usually duplicate records. And this is not something you will need in a regular basis. Anyway, now you know you can do it.
Multiple JOINs
SQL JOINs are always about putting together a pair of tables and finding related objects that obey a given rule (usually, but not limited to, equal values). We can join multiple tables. For instance, to combine 3 tables, you will need 2 joins. And a new join will be necessary for each new table. If you use a join in each step, to combine N tables, you will use N-1 joins. One important thing is that SQL allows you to use different types of joins in the same statement. But DBAs and developers have to be careful on joining too many tables. Several times, I have seen situations where queries demanded 10, 20 tables or even more. For performance reasons, it is not a good idea to do a single query to put all data together. The query optimizer will do a better job if you break your query it into several smaller, simpler queries. Now consider we have a third table, called Table3, shown bellow.
Table3
key3 field1
10/11
sqlservercentral.com/articles//Printable
25/02/2011
www.sqlservercentral.com/articles/T-S
1 2 3 4 5 6
Now let's write a statement to bring the employee's name, the city where he lives and what is his profession. This will demand us to join all 3 tables. Just remember that joins are written in pairs. So first we will join Table1 to Table2. And then we will join Table1 and Table3. The resulting script is shown below.
SELECT t1.key1, t1.field1 as Employee, t2.key2, t2.field1 as City, t3.key3, t3.field1 as Profession FROM Table1 t1 INNER JOIN Table2 t2 ON t1.key2 = t2.key2 INNER JOIN Table3 t3 ON t1.key3 = t3.key3;
As we are running only INNER JOINs, we will have only records that match the combination of the 3 tables. See the output below. key1 3 4 6 Name Erik John Harry key2 1 4 9 City New York Paris Madrid key3 6 4 2 Profession Actor Lawyer Surgeon
Conclusion
Combining data from several tables is something really important when you work with RDBMS's. JOIN operators give you a powerful, fast and flexible way to retrieve the data you need. But be careful, because the wrong choices might do some harm to your application. Either consuming too much processing power on your server, or retrieving the wrong output to your application. With the necessary attention, SQL JOINs are a great feature. And it surely should be part of your personal toolbox. Copyright 2002-2011 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.
sqlservercentral.com/articles//Printable 11/11