Joins/Relations

On RIGHT OUTER JOINS ...

Jeff Smith — Wed, 13 Feb 2008 16:22:25 GMT

Because I feel pretty strongly about this and the entire focus of my blog is writing clear, clean and efficient SQL, I thought I'd repeat my response from a SQLTeam forum question here.

smithje asks this, regarding OUTER JOINS:

Left/Right, does it matter. Is one better than the other? A few years ago consultant on a project for our company advised me to always write my queries to use Left joins. He had worked on the project to convert the original database application to MS SQL when Microsoft took it over. He claimed the design of the query engine handled Left joins more effeciently than right. I converted several queries that processed large datasets to Left join only and got quicker results. I have used Left exclusively since then. Has this concept ever been tested or written about?

My response:

Hi -- they are technically the same, but it is always clearer to use LEFT OUTER JOINS. I strongly recommend to never use RIGHT OUTER JOINS.

When you write a SQL statement, you should express your "base" in your FROM clause, and from there join to auxiliary tables. There is no SELECT statement that cannot be written in that manner, and it is a nice clear, clean way to organize your code. So, if you want ALL customers and ANY orders that match, I think we can all agree that it makes logical sense to express this as:

SELECT ...
FROM customers
OUTER JOIN TO orders

Clearly, we are primarily selecting customers as our "base", and including any Orders that may or may not exist.

As a RIGHT OUTER JOIN, it becomes:

SELECT
FROM Orders
OUTER JOIN TO Customers

which doesn't make sense -- why are we selecting FROM Orders and joining TO Customers, when potentially we want to return Customers that don't have ANY orders?

Anyway, it is rare to get good advice from a consultant, but it appears that you actually did! Avoid RIGHT JOINS, and stick with LEFT JOINS. If a right outer join seems required to make your query work, you should re-write it and change your FROM clause to make it cleaner, simpler and clearer.

(by the same token, I strongly recommend to avoid FULL OUTER JOINS as well.)

Rewriting correlated sub-queries with CASE expressions

Jeff Smith — Wed, 09 Jan 2008 13:42:16 GMT

Here's a very common situation that is very easy to optimize and simplify, submitted via the mailbag:

Nate writes:

Hey, I have a read a bunch of your stuff on your blog and you seem to
be right on the money. I thought maybe you would be able to point me in
the right direction and possibly address this issue on your blog so
others could benefit from your understanding.

I have been searching for the best way to do what I think should be a
simple task in SQL. I have a table full of call history events and I
want to get a summary of some events for each calling party that matches
the form "username(extension)". Using correlated subqueries I do the
following.

SELECT calling_party,

(SELECT SUM(end_time-start_time) AS total_time FROM `event` ei WHERE
event_type=4 AND ei.calling_party = eo.calling_party) AS
total_talking_time,

(SELECT SUM(end_time-start_time) AS total_time FROM `event` ei WHERE
event_type=7 AND ei.calling_party = eo.calling_party) AS
total_ringing_time,

(SELECT MAX(end_time-start_time) AS total_time FROM `event` ei WHERE
event_type=4 AND ei.calling_party = eo.calling_party) AS max_talking_time

FROM `event` eo WHERE calling_party LIKE '%(%)'

GROUP BY calling_party

This works, but ends up taking a really long time to run. I figured
that each subquery was getting executed multiple times. I made a quick php
script that returns the same information but uses multiple queries. I
just query all of the "groups" (SELECT DISTINCT calling_party FROM
`event` WHERE calling_party LIKE '%(%)') and then iterate over that
recordset plugging the actual calling_party value into the where clause of the
aggregate query. The output is identical, but this script runs in well
under a second.

So the question is what is the correct way to do this using SQL? Any
help would be really appreciated.

Hi Nate --

The script as written is making 4 different calls to the calling_party table, and we can reduce this to one call to the table by using CASE expressions to only aggregate the data we need for each column. This is pretty much the standard "static cross-tab" technique to summarize data into multiple columns in a single SELECT.

So, all we need to do is re-write your SELECT like this:

select
calling_party,
sum(case when event_type=4 then end_time-start_time else 0 end) as total_talking_time,
sum(case when event_type=7 then end_time-start_time else 0 end) as total_ringing_time,
max(case when event_type=4 then end_time-start_time else 0 end) as max_talking_time
from
event
where
calling_party LIKE '%(%)'
group by
calling_party

That will return the same results as what you had written, only it should be much more efficient. It is also much shorter. Notice that the CASE expressions ensure that only the data with the specified event_type is including in each aggregate calculation, otherwise we aggregate a value of 0 which has no affect on the results. You can also use a default value of NULL instead of 0 if you'd like, depending on your desired results.

If you have more data in that table for event_types other than 4 and 7, and you only want to return calling_party rows that contain data with those event_types, then be sure to add

and event_type in (4,7)

to your WHERE clause, which will increase the efficiency even further. However, adding that will return different results from your original SELECT (it returns all calling_groups regardless of event_type) so be sure that what you do meets the specifications you require.

As always, be sure that you have proper indexes on all of your tables, and in this case it seems that event_type should certainly be indexed.

see also:

Taking a look at CROSS APPLY

Jeff Smith — Thu, 18 Oct 2007 21:01:20 GMT

Applying a Sub-Query, Joining a Derived Table ...

I think the easiest way to think of CROSS APPLY is that it is like doing a CROSS JOIN with a correlated sub-query instead of a derived table. Let's see if I can explain that .... A derived table is "self-contained", in that all tables and columns in the parent SELECT are not accessible (though variables and parameters can be referenced). For example, consider:

select A.*, b.X
from A
cross join (select B.X from B where B.Val=A.Val) b

That is not legal because A.Val is out of scope within the derived table; this is because the derived table is evaluated independently of the other tables in the SELECT. To limit the rows in table B so that B.Val = A.Val, we must do that outside of the derived table via a join or in the criteria:

select A.*, b.X
from A
cross join (select * from B) b
where A.Val = b.Val

(Of course, the above is equivalent to doing an INNER JOIN to the derived table, or just joining to the table B.)

Also, keep in mind that the scope-of-derived-tables rule isn't just for CROSS JOINS, it's for all JOINS -- CROSS, INNER, OUTER and even UNION; they all use "self-contained" derived tables.

This is in contrast to a correlated sub-query, where the parent SELECT is in scope for the sub-query; the sub-query is evaluated for each row in the query, so the other tables and columns in the SELECT are all available:

select A.*, (select B.X from B where B.Val=A.Val) as X
from A

(Note: I am ignoring for now the fact that returning multiple rows in a sub-query will return an error.)

This is an easy way to think of the difference between CROSS JOIN and CROSS APPLY. CROSS JOIN, as we saw, joins to a derived table; however, CROSS APPLY, despite looking like a JOIN, actually is applying a correlated sub-query. This imposes both the advantages of a correlated sub-query but also the performance implications.

So, we can simply rewrite our first example using CROSS APPLY like this:

select A.*, b.X
from A
cross apply (select B.X from B where B.Val=A.Val) b

Since we are performing an APPLY and not a JOIN, A.Val is in scope and it works just fine.

Table Valued User Defined Functions

Note that the same rules apply when using Table-Valued User-Defined Functions:

select A.*, B.X
from A
cross join dbo.UDF(A.Val) B

is not legal; once again, A.Val is not in scope for the user-defined function. The best we can do before SQL 2005 was to use a correlated sub-query:

select A.*, (select X from dbo.UDF(A.Val)) X
from A

However, that is not logically equivalent; the UDF cannot return more than 1 row or it will result in an error, and wouldn't make logical sense anyway if it did.

Starting with SQL 2005, we can now use CROSS APPLY and it will work fine:

select A.*, b.X
from A
cross apply dbo.UDF(A.Val) b

So, that is one way to think of the difference between a JOIN and an APPLY; a JOIN combines two separate result sets, but APPLY is more of a loop that evaluates one result set over and over for each row in another. This means that, in general, APPLY will be less efficient than a JOIN, just as, in general, correlated sub-queries are less efficient than derived tables. (The optimizer, however, is generally quite good at optimized correlated sub-queries when possible.)

So, why use CROSS APPLY instead of a correlated sub-query? What's the advantage? Actually, quite a lot -- it is much more powerful!

CROSS APPLY can return multiple rows

Unlike correlate sub-queries, CROSS APPLY works with multiple rows. This allows us to do things like "joining" a table to a function that parses a CSV column in that table into multiple rows:

select A.ID, b.Val
from A
cross apply dbo.ParseCSV(A.CSV) b

When the ParseCSV() function returns multiple rows, it simply acts as if we have joined Table A to the function's return table, duplicating the rows in Table A for each row in the joined table. This is not possible with a correlated sub-query, and will result in an error. This is a quick and easy way to parse a table of data into multiple rows in an efficient "set-based" manner when the algorithm requires a complex User-Defined Function. (The CSV is not a great example, but other parsing routines are not as easily accomplished via a JOIN to a numbers table.)

CROSS APPLY can return multiple columns

Again, in a correlated sub-query, we can only return a single value. If we write a SQL statement that returns a running sum, we can use a correlated sub-query like this:

select o.*,
(select sum(Amount) from Order o
where p.OrderDate <= o.OrderDate) as RunningSum
from Order o

However, what if we'd like to return an additional running sum of Orders based on some other criteria (e.g., for orders with the same "OrderCode")? We'd need another correlated sub-query, greatly reducing the efficiency of our SELECT:

select o.*,
(select sum(Amount) from Order o
where p.OrderDate <= o.OrderDate) as RunningSum,
(select sum(Amount) from Order o
where p.OrderCode = o.OrderCode and p.OrderDate <= o.OrderDate) as SameCode
from Order o

However, we can easily re-write that using a single CROSS APPLY:

select o.*, rs.RunningSum, rs.SameCode
from Order o
cross apply
(
   select
     sum(Amount) as RunningSum,
     sum(case when p.OrderCode = o.OrderCode then Amount else 0 end) as SameCode
   from Order P
   where P.OrderDate <= O.OrderDate
) rs

So, we get the benefit of return multiple columns like a derived table, and we also get the ability to reference outer values in our SELECT to use in criteria and CASE statements. Very, very powerful.

CROSS APPLY also allows us to quickly get columns from the "previous" row in a table quite easily:

select o.*, prev.*
from Order o
cross apply
(
   select top 1 *
   from Order P where P.OrderDate < O.OrderDate
   order by OrderDate DESC
) prev

We can express the running total and counts as CROSS JOINS or INNER JOINS by reworking a correlated sub-query, but using TOP and referencing the outer SELECT is not easily done in that manner.

Note that the above CROSS APPLY will not return any orders without a previous order; we would use OUTER APPLY to ensure that all orders are returned even if no previous orders exist:

select o.*, prev.*
from Order o
outer apply
(
   select top 1 *
   from Order P where P.OrderDate < O.OrderDate
   order by OrderDate DESC
) prev

We can also CROSS APPLY to a Table-Valued User Defined Function that returns exactly one row, but with multiple columns, to return separate pieces of data from a single function call. For example, we can parse an email address into separate username and domain columns. A few months back I wrote a SQL Team article that discusses that concept.

Summary

CROSS and OUTER APPLY are very powerful and can be very useful, but we must be careful to use them only when necessary; I am still testing the possibilities, but in general an APPLY will tend to be not as efficient as a JOIN. In addition, APPLY is mostly demonstrated by applying table-valued user-defined functions, but it can be used with in-line SELECT statements as well.

see also:

Be Careful When Mixing INNER and OUTER Joins

Jeff Smith — Thu, 11 Oct 2007 18:39:49 GMT

I had previously written about the danger of Criteria on Outer Joins, but recently another situation popped up that occasionally causes confusion with OUTER JOINS that I thought I might address. The issue is when you have multiple tables joined in a single SELECT, and you mix OUTER and INNER JOINS together. The end result doesn't always seem to "work", and it can be tricky to understand exactly why and how to fix it without incurring additional unintended side effects.

Consider the following schema and sample data:

create table People
(
    PersonID int identity primary key,
    PersonName varchar(20)
)

create table PetTypes
(
    PetTypeID int identity primary key,
    PetType varchar(10)
)

create table Pets
(
    PetID int identity primary key,
    PetTypeID int references PetTypes(PetTypeID) not null,
    PetName varchar(10),
    OwnerID int references People(PersonID) not null
)

insert into People (PersonName)
select 'Fred Flintstone' union all
select 'Barney Rubble' union all
select 'George Jetson'

insert into PetTypes (PetType)
select 'Dinosaur' union all
select 'Hopparoo'

insert into Pets (PetTypeID, PetName, OwnerID)
select 1,'Dino',1 union all
select 2,'Hoppy',2

(note: I actually don't remember Hoppy at all from the cartoon, but I read about him here)

Notice that all pets must have an owner, and all pets must have a PetType that indicates what they are.

If we wish to return all People and their pets, if any, we would use an OUTER JOIN like this:

select People.PersonName, Pets.PetName
from People
left outer join Pets on Pets.OwnerID = People.PersonID

PersonName           PetName
-------------------- ----------
Fred Flintstone      Dino
Barney Rubble        Hoppy
George Jetson        NULL

(3 row(s) affected)

We use the OUTER JOIN so that we still return George Jetson, even though he has no Pet. Since there is no Pet for him, NULLS are returned for all columns in the Pets table for that row. So far so good, this is exactly what we want, things are working great.

Now, suppose we wish to indicate the PetType as well for each Pet. All Pets must have a PetType since the column is not nullable, so it appears that we can simply add an INNER JOIN between Pets and PetTypes to our previous SELECT to include this information. Let's give it a shot:

select People.PersonName, Pets.PetName, PetTypes.PetType
from People
left outer join Pets on Pets.OwnerID = People.PersonID
inner join PetTypes on Pets.PetTypeID = PetTypes.PetTypeID

PersonName           PetName    PetType
-------------------- ---------- ----------
Fred Flintstone      Dino       Dinosaur
Barney Rubble        Hoppy      Hopparoo

(2 row(s) affected)

Where did George Jetson go? We know that we can do an INNER JOIN between Pets and PetTypes since all Pets will always have a PetType match, and we did an OUTER JOIN from People to Pets so ensure that all People are returned regardless of having a pet or not. On paper, then, it might seem that something isn't working correctly since the code seems solid.

Well, we need to look a little more closely. If we go back to our original OUTER JOIN (that included George in the results) and add the PetTypeID column from the Pets table to it, we get:

select People.PersonName, Pets.PetName, Pets.PetTypeID
from People
left outer join Pets on Pets.OwnerID = People.PersonID

PersonName           PetName    PetTypeID
-------------------- ---------- -----------
Fred Flintstone      Dino       1
Barney Rubble        Hoppy      2
George Jetson        NULL       NULL

(3 row(s) affected)

Notice that the PetTypeID column is NULL for George. SQL Server processes the joins in the order you specify, so it first gets the results from the OUTER JOIN between People and Pets, and then uses those results to INNER JOIN to the PetTypes table. The NULL PetTypeID returned for George Jetson doesn't match any rows in the PetTypes table, and the INNER JOIN requires a match, so George is not returned in the results.

So how do we fix this? One approach commonly used, which should really be avoided, is to simply change the INNER JOIN between Pets and PetTypes to a LEFT OUTER JOIN as well:

select People.PersonName, Pets.PetName, PetTypes.PetType
from People
left outer join Pets on Pets.OwnerID = People.PersonID
left outer join PetTypes on Pets.PetTypeID = PetTypes.PetTypeID

PersonName           PetName    PetType
-------------------- ---------- ----------
Fred Flintstone      Dino       Dinosaur
Barney Rubble        Hoppy      Hopparoo
George Jetson        NULL       NULL

(3 row(s) affected)

This appears to do the trick. However, it is not the equivalent of our original intentions! We initially wrote an INNER JOIN between Pets and PetTypes, since we do not want to return any Pets that do not have a corresponding PetType. In this case, it is not an issue because PetTypeID cannot be NULL for a Pet, but what if it could be? The results will not be logically the same if we switch that INNER JOIN to an OUTER JOIN.

For example, let's create a new version of the Pets table, that allows for NULL pet types:

drop table Pets
go
create table Pets
(
    PetID int identity primary key,
    PetTypeID int references PetTypes(PetTypeID),
    PetName varchar(10),
    OwnerID int references People(PersonID) not null
)

insert into Pets (PetTypeID, PetName, OwnerID)
select 1,'Dino',1 union all
select 2,'Hoppy',2 union all
select null,'Baby Puss',1

Notice now that we've included Fred's cat, Baby Puss, but we did not assign him a PetType.

Let's now re-run the original OUTER JOIN/INNER JOIN statement that excluded George:

The same results are returned; George is excluded for reasons we discovered (and are trying to fix), and Baby Puss is missing because we explicitly asked for an INNER JOIN between Pets and PetTypes. The only issue we should have, then, with the previous SELECT is that George is missing and we'd like to see him -- Baby Puss should be excluded by design. (If that isn't clear, let me know) So, if we switch the second join to an OUTER JOIN in an attempt to fix things to get George returned, we now get:

select People.PersonName, Pets.PetName, PetTypes.PetType
from People
left outer join Pets on Pets.OwnerID = People.PersonID
left outer join PetTypes on Pets.PetTypeID = PetTypes.PetTypeID

PersonName           PetName    PetType
-------------------- ---------- ----------
Fred Flintstone      Dino       Dinosaur
Fred Flintstone      Baby Puss NULL
Barney Rubble        Hoppy      Hopparoo
George Jetson        NULL       NULL

(4 row(s) affected)

Notice that suddenly Baby Puss appears! That is because we changed our join from Pets to PetTypes from an INNER to an OUTER. So, just changing INNER JOINS to OUTER JOINS to "fix" this problem may have unintended side effects, and your query is no longer logically the same! It may work in most cases, or in all cases depending on your constraints and relations, but it is important to understand that logically you have completely changed what you are asking for.

The best solution is to use a derived table to encapsulate the INNER JOIN between Pets and PetTypes. Then, we simply select FROM the People table and OUTER JOIN to the derived table. This returns the results we are looking for:

select
People.PersonName, Pets.PetName, Pets.PetType
from
People
left outer join
(
select Pets.ownerID, Pets.PetName, PetTypes.PetType
from Pets
inner join PetTypes on Pets.PetTypeID = PetTypes.PetTypeID
)
Pets
on
Pets.OwnerID = People.PersonID

PersonName           PetName    PetType
-------------------- ---------- ----------
Fred Flintstone      Dino       Dinosaur
Barney Rubble        Hoppy      Hopparoo
George Jetson        NULL       NULL

(3 row(s) affected)

That's more like it! Note that we could also use a Common Table Expression if you are using SQL 2005.

An alternative option, which also works correctly, is to nest your join expression like this:

select People.PersonName, Pets.PetName, PetTypes.PetType
from People
left outer join
(Pets inner join PetTypes on Pets.PetTypeID = PetTypes.PetTypeID)
on Pets.OwnerID = People.PersonID

That returns the correct results and is logically accurate, but I find it can be confusing to read and a little more difficult to maintain. In general, I have found that most database programmers tend to avoid nested joins expressions. It's up to you to decide which option you'd prefer to use.

So, be careful when mixing INNER and OUTER joins; it can be tricky to hunt down unintended results and side effects. If you use Derived Tables (or nested joins) the way you'd use parenthesis in a math or boolean equation to express your logical order of precedence, you can make your code cleaner and more readable and you can ensure that you get back the exact results you intended.

see also:

Creating CSV strings in SQL: Should Concatenation and Formatting Be Done at the Database Layer?

Jeff Smith — Tue, 09 Oct 2007 19:02:57 GMT

A question I see very often in the SQLTeam forums is how to return data in a summarized form by concatenating a list of values into a single CSV column. This can be done fairly easily in T-SQL, but as the formatting and concatenation requirements becomes more elaborate, be sure to ask yourself: Am I forcing presentation code into the database layer? read more...

"Nested WHERE-IN" Anti-Pattern Follow-up; More on Derived Tables (sub-queries)

Jeff Smith — Fri, 13 Jul 2007 13:33:54 GMT

A quick follow up to the "Nested WHERE-IN" anti-pattern post from yesterday ... If you didn't get a chance, be sure to read the comments from that post as well, there are some great points in there so far. read more...

The "Nested WHERE-IN" SQL Anti-Pattern

Jeff Smith — Thu, 12 Jul 2007 16:50:44 GMT

There's a fascinating technique that I see many beginners use when writing SQL statements, and I call it the "Nested WHERE-IN" anti-pattern. It is, unfortunately, a common SQL technique used to avoid JOINS at all costs. read more...

Using GROUP BY to avoid self-joins

Jeff Smith — Tue, 12 Jun 2007 15:35:33 GMT

Sometimes, it appears that a necessary solution to common SQL problems is to join a table to itself. While self-joins do indeed have their place, and can be very powerful and useful, often times there is a much easier and more efficient way to get the results you need when querying a single table.

read more...

Criteria on Outer Joined Tables

Jeff Smith — Mon, 14 May 2007 14:12:33 GMT

When using an OUTER JOIN, you should put criteria on the outer table in the join condition, not in the WHERE clause. However, I often see a "workaround" to avoid this simple and solid rule, which might seem to work but actually doesn't. Since it is hard to explain why over and over in forum posts, I thought it might be helpful to address that here once and for all with an example.

read more...

Thinking Set-Based .... or not?

Jeff Smith — Mon, 30 Apr 2007 17:03:11 GMT

So, I hear you're a "set-based SQL master" ! As Yoda once said, you've "unlearned what you have learned". You've trained yourself to attack your database code not from a procedural, step-by-step angle, but rather from the set-based "do it all at once" approach. However, don't completely forget the most important skill that you learned in the procedural world!

read more...