Comments on: SQL Tip: Using EXISTS to generate a column in place of a subquery

By: John Whish

John Whish — Tue, 24 Feb 2009 15:05:10 +0000

Just a thought, but wouldn’t you be better off using a derived table? As far as I know the subquery will execute for each row, whereas a derived table runs once.

By: Ben Nadel

Ben Nadel — Mon, 02 Feb 2009 18:17:13 +0000

IF(), COALESCE()… you can always use a CASE statements in the SELECT:

(CASE WHEN EXISTS( … ) THEN 1 ELSE 0 END) AS IsEditor

By: brian

brian — Sun, 01 Feb 2009 18:38:18 +0000

Sounds like the equivalent of Postgres’ COALESCE(). I’ll try running some additional analysis when I get some time for the outer join as well as some other scenarios to better flesh out the trade offs in approaches.

By: Zack Steinkamp

Zack Steinkamp — Sun, 01 Feb 2009 17:47:59 +0000

Brian — IF() is a built-in function to MySql that you can use in your SELECT fields to mutate a value.

Without the IF(), the second column value would either be “Editor” or NULL. If I was building the app, I’d leave it at that and test for NULL when rendering the output.

I’m curious to see a performance comparison to the EXISTS(-subquery-) method vs. the LEFT JOIN method…

By: brian

brian — Sun, 01 Feb 2009 17:24:13 +0000

@Zack – The concept is intended to be database agnostic although Postgres does support all JOIN syntaxes (INNER, OUTER, CROSS, etc). Is the IF() a MySQL extension for processing outer joins? There are many ways to skin the cat of coalescing values but the power of the EXISTS approach is that it can be significantly more narrow than a typical JOIN would afford. My query should also be portable across most database platforms, although I believe database portability to be a red herring concern for most web applications.

I find the more correctly normalized my schema, the more hoops I need to jump through when it comes time to reporting. Some people accomplish it with reporting packages but I typically roll up some queries as needed. I have yet to find a really good reporting suite with an acceptable end-user interface for non-technical users. Actuate has some tools on top of BIRT that come close but I’m still waiting for “the one” I can drop into my app.

By: Zack Steinkamp

Zack Steinkamp — Sun, 01 Feb 2009 01:25:12 +0000

Not sure if Postgres has a “LEFT JOIN”, but in MySql, this can be done without a subquery…

SELECT name, IF(option_name = "Editor", 1, 0) FROM customers LEFT JOIN options ON (customers.id = options.customer_id) AND options.option_name='Editor';

The nature of the LEFT JOIN is that it includes all rows from the “left” table, and uses NULLs for values from the right table if there is not a row to join.

By: brian

brian — Sat, 31 Jan 2009 18:51:54 +0000

@Andrew – I knew someone was going to point it out! Technically you are correct in the integer vs boolean and your fix would correct it. Consuming those two queries above with ColdFusion however would be equivalent. Both approaches would allow you to do say:

...

Thanks though, you are definitely right. I thought about fixing the first query but it was late and I wanted to go home.

By: Andrew

Andrew — Sat, 31 Jan 2009 18:47:05 +0000

I realize this is a simplified example, but my main issue with these 2 sql selects is that they are not equivalent. At the postgres level EXISTS returns a boolean, where as count(*) returns a bigint.

As an example, since options doesn’t have a unique contraint on customer_id and option_name it’s possible that a customer_id has multiple Editor option_name entries, and the result of the 2 sql will be different. Now if the first select was ‘… select count(*) > 0 from options …’ then replacing it with exists would be equivalent.

However, I whole heartily agree with using EXPLAIN.