Welcome Log Out My Account FAQ Go Pro!

My Profile Contacts Subscriptions My Stuff Preferences Send a Message Log In Join TechRepublic FAQ Go Pro! ZDNet SmartPlanet TechRepublic

TechRepublic

Home Blogs Downloads Newsletters Q&A Discussions Training Research Library IT Management Development IT Support Data Center Networks Security Leadership Career Compliance IT Consultant ITIL Project Management Business Intelligence

Web Development Software Development Mobile Development Help Desk Desktop Applications Mobile Computing Microsoft Windows Apple Linux Cloud Computing Database Administration Servers Storage Virtualization LAN/WAN Wireless Unified Communications VoIP Anti-Malware Compliance IT Risk Management
1

Search

All of TechRepublic Publications Library

Collapse -

10 ways to diagnose ailing PCs

Top IT skills wanted for 2012

What IT will look like in 2015 17Comments more +

Email Print Add to Favorites Del.icio.us Digg Hacker News LinkedIn Reddit Technorati

Basic and complex SQL joins made easy

By Shelley Doll July 8, 2002, 7:00am PDT If youre new to SQL, joins can be a daunting concept. There are many different types of joins and seemingly little information available that explains and compares them. But after you digest a few basic concepts, the practice of joins actually isnt very difficult. Lets look at the fundamentals that should give you a solid, functional knowledge of how to use the JOIN statement. We wont consider some more advanced JOIN statement concepts, such as aliasing, join order, conceptual joins, and join hints. While the descriptions Ill present in this article relate directly to Microsoft SQL Server, they also apply to any SQL92compliant database. The JOIN concept JOIN is a query clause that can be used with the SELECT, UPDATE, and DELETE data query statements to simultaneously affect rows from multiple tables. There are several distinct types of JOIN statements that return different data result sets. Joined tables must each include at least one field in both tables that contain comparable data. For example, if you want to join a Customer table and a Transaction table, they both must contain a common element, such as a CustomerID column, to serve as a key on which the data can be matched. Tables can be joined on multiple columns so long as the columns have the potential to supply matching information. Column names across tables don't have to be the same, although for readability this standard is generally preferred.

When you do use like column names in multiple tables, you must use fully qualified column names. This is a dot notation that combines the names of tables and columns. For example, if I have two tables, Customer and Transaction, and they both contain the column CustomerID, Id use the dot notation, as in Customer.CustomerID and Transaction.CustomerID, to let the database know which column from which table Im referring. Now that weve examined the basic theory, lets take a look at the various types of joins and examples of each. The basic JOIN statement A basic JOIN statement has the following format: SELECT Customer.CustomerID, TransID, TransAmt FROM Customer JOIN Transaction ON Customer.CustomerID = Transaction.CustomerID; In practice, you'd never use the example above because the type of join is not specified. In this case, SQL Server assumes an INNER JOIN. You can get the equivalent to this query by using the statement: SELECT Customer.CustomerID, TransID, TransAmt FROM Customer, Transaction; However, the example is useful to point out a few noteworthy concepts:

TransID and TransAmt do not require fully qualified names because they exist in only one of the tables. You can use fully qualified names for readability if you wish. The Customer table is considered to be the left table because it was called first. Likewise, the Transaction table is the right table. You can use more than two tables, in which case each one is naturally joined to the cumulative result in the order they are listed, unless controlled by other functionality such as join hints or parenthesis. You may use WHERE and ORDER BY clauses with any JOIN statement to limit the scope of your results. Note that these clauses are applied to the results of your JOIN statement. SQL Server does not recognize the semicolon (;), but I use it in the included examples to denote the end of each statement, as would be expected by most other RDBMSs.

The notorious CROSS JOIN The CROSS JOIN has earned a bad reputation because its very resource intensive and returns results of questionable usefulness. When you use the CROSS JOIN, you're given a result set containing every possible combination of the rows returned from each table. Take the following example: SELECT CustomerName, TransDate, TransAmt FROM Customer CROSS JOIN Transaction; With the CROSS JOIN, you arent actually free to limit the results, but you can use the ORDER BY clause to control the way they are returned. If the tables joined in this example contained only five rows each, you would get 25 rows of results. Every CustomerName would be listed as associated with every TransDate and TransAmt.

I really did try to come up with examples where this function was useful, and they were all very contrived. However, Im sure someone out there is generating lists of all their products in all possible colors or something similar, or we wouldnt have this wonderful but dangerous feature. The INNER JOIN drops rows When you perform an INNER JOIN, only rows that match up are returned. Any time a row from either table doesnt have corresponding values from the other table, it is disregarded. Because stray rows arent included, you dont have any of the left and right nonsense to deal with and the order in which you present tables matters only if you have more than two to compare. Since this is a simple concept, heres a simple example: SELECT CustomerName, TransDate FROM Customer INNER JOIN Transaction ON Customer.CustomerID = Transaction.CustomerID; If a row in the Transaction table contains a CustomerID thats not listed in the Customer table, that row will not be returned as part of the result set. Likewise, if the Customer table has a CustomerID with no corresponding rows in the Transaction table, the row from the Customer table wont be returned. The OUTER JOIN can include mismatched rows OUTER JOINs, sometimes called complex joins, arent actually complicated. They are socalled because SQL Server performs two functions for each OUTER JOIN. The first function performed is an INNER JOIN. The second function includes the rows that the INNER JOIN would have dropped. Which rows are included depends on the type of OUTER JOIN that is used and the order the tables were presented. There are three types of an OUTER JOIN: LEFT, RIGHT, and FULL. As youve probably guessed, the LEFT OUTER JOIN keeps the stray rows from the left table (the one listed first in your query statement). In the result set, columns from the other table that have no corresponding data are filled with NULL values. Similarly, the RIGHT OUTER JOIN keeps stray rows from the right table, filling columns from the left table with NULL values. The FULL OUTER JOIN keeps all stray rows as part of the result set. Here is your example: SELECT CustomerName, TransDate, TransAmt FROM Customer LEFT OUTER JOIN Transaction ON Customer.CustomerID = Transaction.CustomerID; Customer names that have no associated transactions will still be displayed. However, transactions with no corresponding customers will not, because we used a LEFT OUTER JOIN and the Customer table was listed first. In SQL Server, the word OUTER is actually optional. The clauses LEFT JOIN, RIGHT JOIN, and FULL JOIN are equivalent to LEFT OUTER JOIN, RIGHT OUTER JOIN, and FULL OUTER JOIN, respectively. Another addition to your SQL toolbox Although the JOIN statement is often perceived as a complicated concept, you can now see that its a powerful timesaving resource thats relatively easy to understand. Use this

functionality to get related information from multiple tables with a single query and to skillfully reference normalized data. Once youve mastered JOINs, you can elegantly maneuver within even the most complex database. 17 Comments Add Your Opinion

Join the conversation!

Follow via: RSS Email Alert Go to comment Just In

RE: Basic and complex SQL joins made easy

samad.maajid@... 1st Oct 2008 The information provided was extremely informative. However, if someone can provide me with more examples of JOIN, it will be really helpful. Regards, Maajid samad.maajid@gmail.com Community Preferences View: Expanded

Collapsed Expanded

Show: 50

25 50 100 All

0 Votes +-

Example is NOT a cross join

MikeSQLDBA 7th Jul 2002

The author stated: A basic JOIN statement has the following format: SELECT Customer.CustomerID, TransID, TransAmt FROM Customer JOIN Transaction ON Customer.CustomerID = Transaction.CustomerID; In practice, you?d never use the example above because the type of join is not specified. SQL Server assumes an INNER JOIN if not specified, unless there is no WHERE clause, as in the statement above. In this case, the JOIN is treated as a CROSS JOIN (explained later). As it stands, you can get the equivalent to this query by using the statement: SELECT Customer.CustomerID, TransID, TransAmt FROM Customer, Transaction;

I have to disagree: SELECT Customer.CustomerID, TransID, TransAmt FROM Customer JOIN Transaction ON Customer.CustomerID = Transaction.CustomerID; is NOT a cross join with SQL Server 7, it is in fact an inner join, assuming of course the CustomerID is the primary key for table Customer and that (CustomerID, TransID) is the primary key for table Transaction. A cross join would join each row of Customer with each row of Transaction, regardless of the customer id. That does not occur with the author's first example. The customer id's are matched between the two tables as expected.

Reply Flag Favorite

PreviousNext PreviousNext 0 Votes +-

I stand corrected

shelleydoll 8th Jul 2002 You are correct - The basic JOIN example provided is NOT a CROSS JOIN, because it does specify fields to be joined on. MS SQL Server will treat this as an INNER JOIN. I have requested that the text in the article be changed. Thank you for catching this!

Reply Flag Favorite

0 Votes +-

Cross Join _IS_ Cross Join

DaraLynx@... 15th May 2003 The Cross Join specified _IS_ a cross join because of the specification in the join statement. select * from a CROSS JOIN b on a.key = b.key;

NOTE: the word CROSS before JOIN. Her example indicated that the assumption would be inner joinFOR THE FIRST EXAMPLE which is TRUE for most SQL (however one database in particular -Teradata - may implement a cross join in the optimizing of the join for large/small table joins) It was the SECOND EXAMPLE that was a CROSS JOIN because of the use of CROSS before the word JOIN in the SQL. Am I reading you wrong?

Reply Flag Favorite

0 Votes +-

Cross joins

R. A. 8th Jul 2002 You said that "SELECT Customer.CustomerID, TransID, TransAmt FROM Customer JOIN Transaction ON Customer.CustomerID = Transaction.CustomerID; "...In this case, the JOIN is treated as a CROSS JOIN (explained later). As it stands, you can get the equivalent to this query by using the statement: "SELECT Customer.CustomerID, TransID, TransAmt FROM Customer, Transaction;" What am I missing here? The first example doesn't look like a cross join to me, as you are specifying that for a row to be selected the customer id columns have to match.

Reply

Flag Favorite

0 Votes +-

Another bad article

jvm_cop+techrep@... 8th Jul 2002 Not only is the first example rather obviously not a "cross join" but there was no explanation of the notion that a join almost always results in redundant information. That is, when you join tables, you are undoing the "normalization" that was done for the purpose of having each "fact" in the database stored in exactly one place. In the Customer / Transaction example, joining the tables causes the customer information to be repeated N times, where N is the number of transaction records forthe customer.

Reply Flag Favorite

0 Votes +-

Another bad remark

Stonie-ASP 9th Jul 2002 In the real world the joining of tables is a common task. Sure normalization is being undone. But what other solution are you suggesting? Surely you must be working with simple data if you don?t perform joins? Stonie.

Reply Flag Favorite

0 Votes +-

Read the email discussion

cackar@... 10th Jul 2002 The fact that the example is incorrect has been acknowledged (see 8-JUN-2002 discussion thread) and the author has requested that the article text be corrected. So enough already.

Second, what are you saying...don't ever join anything???? ...And joins don't "almost always" result "in redundant information" unless you choose to include redundant data columns in your select statement. Sheesh!!

Reply Flag Favorite

0 Votes +-

redundant data ? what redundant data ?

f_eriksen@... 19th Sep 2002 The purpose of normalization is, as you say, to not store redundant data. There is however never been said to the best of my knowledge, that one should not join these tables in purpose of display, analysis etc.. A resultset does not constitute asstorage (beyond the appropiate caches perhaps..), and no normalization has been 'undone' as you say. And there is no guarantee that the result of a join will result in repeating data, depends on data at hand does it not ? and what about aggregated sql's ? union all constructs ? cube/rollup's ? What is your data, that allows you to operate in a manner that means you never have to join anything ? Cant think of any business in real world that has such kind of data ? Most stupid post i've seen here at builder..

Reply Flag Favorite

0 Votes +-

Not a Cross Join

Jay.Bonk@... 9th Jul 2002 The example states that the returned result set would consist of 25 rows, this is incorrect. The result set would only contain 5 rows. As in the example below...

CREATE TABLE TabA ( Col1 INT, Col2 VARCHAR(20) ) GO CREATE TABLE TabB ( Col1 INT, Col2 VARCHAR(20) ) GO INSERT INTO TabA VALUES (1,'TabA-Col1') INSERT INTO TabA VALUES (2,'TabA-Col2') INSERT INTO TabA VALUES (3,'TabA-Col3') INSERT INTO TabA VALUES (4,'TabA-Col4') INSERT INTO TabA VALUES (5,'TabA-Col5') INSERT INTO TabB VALUES (1,'TabB-Col1') INSERT INTO TabB VALUES (2,'TabB-Col2') INSERT INTO TabB VALUES (3,'TabB-Col3') INSERT INTO TabB VALUES (4,'TabB-Col4') INSERT INTO TabB VALUES (5,'TabB-Col5') GO SELECT TabA.Col1, TabB.Col1, TabA.Col2, TabB.Col2 FROM TabA JOIN TabB ON TabA.Col1 = TabB.Col1 Returns....

1 1 TabA-Col1 TabB-Col1 2 2 TabA-Col2 TabB-Col2 3 3 TabA-Col3 TabB-Col3 4 4 TabA-Col4 TabB-Col4 5 5 TabA-Col5 TabB-Col5

Reply Flag Favorite

0 Votes +-

error acknowledged, enough already

cackar@... 10th Jul 2002 The fact that the example is incorrect has been acknowledged (see 8-JUN-2002 discussion thread) and the author has requested that the article text be corrected. So enough already.

Reply Flag Favorite

0 Votes +-

Technical articles on this site, please!

Skiffrace2 12th Jul 2002 Builder.com should use it's server space and our connection bandwidth on something better than "2+2=4"-level "technical articles".

Reply Flag Favorite

0 Votes +-

It's only basic because....

privately_owed 12th Jul 2002 ...you already know it.

Reply Flag Favorite

0 Votes +-

JOIN might be the thing....

M Hamil 16th Jul 2002 Appreciate the article. Could you please give me a little more info for what I am trying to do. I think that JOIN might be what I need. From one table (CELLS) I want to select records that meet certain conditions, as shown in the first WHERE clause. Then from the same table I'd like to select the records that meet the second WHERE clause condition. I want the output all together. Would this be joining a table to itself? SELECT ce.cell_id FROM cells ce,

cell_names cn, extent_typeet, extent_size es, cell_extent_copy cec WHERE ce.cell_id = cn.cell_id and ce.cell_id = cec.cell_id_nmbr and cn.cell_name_current = 'Y' and ce.cell_size = es.extent_size_name and ce.cell_type = et.extent_type_descr; SELECTce.cell_id FROM cells ce WHERE ce.CELL_TYPE is null;

Reply Flag Favorite

0 Votes +-

OR keyword

shelleydoll 17th Jul 2002 Actually, if I understand what you're looking for correctly, it's much more simple a problem than that. Please tell me if this is incorrect: you're looking for a list of cell ids that either match the first query or the second query. If that's thecase, you can use the OR keyword in your WHERE clause. Your query should go something like: SELECT ce.cell_id FROM cells ce, cell_names cn, extent_type et, extent_size es, cell_extent_copy cec WHERE (ce.cell_id = cn.cell_id and ce.cell_id = cec.cell_id_nmbr and cn.cell_name_current = 'Y' and ce.cell_size = es.extent_size_name and ce.cell_type = et.extent_type_descr) OR (ce.CELL_TYPE is null);

Reply Flag Favorite

0 Votes

+-

duplicate NULL rows

M Hamil 18th Jul 2002 You are correct, I am looking for a list of cell ids that either match the first query or the second query. However, when I tried the code in your response, it returned the row with the NULL value numerous times (my data only has 1 row with a NULL value) while the rest of the non-null valued rows were returned correctly. What did seem to work though was this code: SELECT ce.cell_id FROM cell_names cn, extent_type et, extent_size es, cell_extent_copy cec WHERE ce.cell_id = cn.cell_id and ce.cell_id = cec.cell_id_nmbr and cn.cell_name_current = 'Y' and ce.cell_size = upper(es.extent_size_name) and ce.cell_type = upper(et.extent_type_descr) UNION SELECT ce.cell_id FROM cells ce, cell_names cn, extent_type et, extent_size es, cell_extent_copy cec WHERE ce.cell_id = cn.cell_id and ce.cell_id = cec.cell_id_nmbr and cn.cell_name_current = 'Y' and ce.cell_size = upper(es.extent_size_name) and ce.cell_type is null; And also the following code provided the correct results: SELECT distinct (ce.cell_id) FROM cells ce, cell_names cn, extent_type et, extent_size es, cell_extent_copy cec WHERE (ce.cell_id= cn.cell_id and ce.cell_id = cec.cell_id_nmbr and cn.cell_name_current = 'Y' and ce.cell_size = upper(es.extent_size_name) ) and (ce.cell_type = upper(et.extent_type_descr) or

ce.cell_type is null); I'mnot sure why the 'distinct' had to be put in. Any idea? As you've probably noticed, I posted this problem to you also in a SQL Query article you wrote. Because someone else may be interested in this topic but thinking about it along those thoughts, I will copy this response there as well. Thank you. MH

Reply Flag Favorite

0 Votes +-

I agree with Lamont!

fac 29th Aug 2002 SWPDEVPR, If you are a database expert then don't read the articles. I find them very informative as a beginner and to be honest it was the easiest to understand description I've seen of SQL Server Joins. I think people who are willing to provide the time to write articles should be applauded and not ridiculed. She acknowledged her error and fixed it!!! If you are so good, why don't you write some articles for advanced users! (:-)) Frank

Reply Flag Favorite

0 Votes +-

RE: Basic and complex SQL joins made easy

samad.maajid@... 1st Oct 2008 The information provided was extremely informative. However, if someone can provide me with more examples of JOIN, it will be really helpful. Regards, Maajid samad.maajid@gmail.com

Reply

Flag Favorite

Join the conversation

Subject (Max length: 75 characters)

Comment
10 ar 97961 Shelley Doll 1046273 Basic and comple http://w w w .techr 10878

Add Your Opinion Alert me when new comments are made Join the TechRepublic Community and join the conversation! Signing-up is free and quick, Do it now, we want to hear your opinion. Join Login <SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript" SRC="http://ad.doubleclick.net/adj/us.geo.cnetasia/mpu_techrep;sz=300x250;ptile=1;dcopt=i st;adch=TECHREPUBLIC;adch2=251;ord=2011.10.03.20.00.56?"></SCRIPT> <NOSCRIPT> <A href="http://adlog.com.com/adlog/e/r=8830&amp;sg=229965&amp;o=13054%253A10878% 253A&amp;h=cn&amp;p=&amp;b=9&amp;l=&amp;site=11&amp;pt=2403&amp;nd=10878 &amp;pid=&amp;cid=1046273&amp;pp=100&amp;e=&amp;rqid=00c13-ade18:4E89DB68CE1F5&amp;orh=co.in&amp;oepartner=&amp;epartner=&amp;ppartner=&a mp;pdom=google.co.in&amp;cpnmodule=&amp;count=&amp;ra=122.174.36.13&amp;pg=b s9W2QoPOh4AAGJyvIkAAAAK&amp;t=2011.10.03.20.00.56&event=58/http://ad.doublecl ick.net/jump/us.geo.cnetasia/mpu_techrep;sz=300x250;ptile=1;dcopt=ist;adch=TECHREPU BLIC;adch2=251;ord=2011.10.03.20.00.56?"><IMG SRC="http://ad.doubleclick.net/ad/us.geo.cnetasia/mpu_techrep;sz=300x250;ptile=1;dcopt=i st;adch=TECHREPUBLIC;adch2=251;ord=2011.10.03.20.00.56?" BORDER="0" WIDTH="300" height="250"></A> </NOSCRIPT> Keep Up with TechRepublic

TR Dojo IT Career Subscribe Today

Discover more newsletters

10 Things

Sanity Check Subscribe Today Follow us however you choose!

Facebook Twitter Linkedin Digg RSS Android iPhone

View All Hot Discussions

103 Still reading banned books

34 10 ways to diagnose ailing PCs: Step by step

21 Making money on free software

37 10 ways to keep Excel from biting you in the butt

Start a Discussion
Vendor Showcase

Get your front row seat to every argument at ZDNet's The Great Debate!

View All Hot Questions

9 Desktop Icons won't stay hidden

Do i have a bad processor?

4 Wireless Repeater

3 NEED HELP WITH DMP FILE????

Ask a Question

A CNET Professional Brand On ZDNet Sony Handycam HDR-PJ10 photos and image samples TechRepublic Search

Trending Topics

Databases server IT OPERATIONS SECURITY Microsoft Windows XP technical support information technology training mobile MANAGEMENT network Microsoft Office Application Development NETWORKING

Featured TechRepublic Pro Downloads

500 Things You Need To Know To Succeed In Your IT career

101 Microsoft Windows Vista tips, tweaks, and hacks you need to know

101 Microsoft Windows XP Tips, Tweaks, and Hacks You Need to Know

Quick Reference: Linux Commands

Explore

Blogs Downloads Members Q&A DIscussions Training Store Research Library Photos Videos

Services

About Us Membership Newsletters RSS Feeds Site Map Site Help & Feedback FAQ Advertise Reprint Policy

Popular on CBS sites: US Open | PGA Championship | iPad | Video Game Reviews | Cell Phones

 2011 CBS Interactive. All rights reserved. Privacy Policy | Ad Choice | Terms of Use | Advertise | Jobs A ZDNet Web Site | Visit other CBS Interactive Sites: