Comments on: Good SQL Querying http://www.pythian.com/news/1116/good-sql-querying/ News and views from Pythian DBAs Fri, 10 Feb 2012 13:01:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Gints Plivna http://www.pythian.com/news/1116/good-sql-querying/#comment-237304 Gints Plivna Wed, 16 Jul 2008 07:01:48 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-237304 I've tried to summarize various join types here http://www.gplivna.eu/papers/sql_join_types.htm I'd like to add that natural join syntax is very dangerous and actaully asks for trouble as soon as table structure changes. Speaking about join criteria vs filter criteria - it doesn't really matter for inner joins where these are written. However for outer joins it really does matter where another criteria are written - result changes - see chapter 6.4 Difference between predicates in ON clause vs. predicates in WHERE clause in my article. And speaking cross join vs inner join - the biggest problem is that MySQL had mixed them up, and historically cannot probably so easy enforce cross join like real cartesian join raising error when on clause is applied and inner join like normal inner join. I think the situation is the same like old outer join operators in Oracle (+) or MS SQL (*= and =*). And speaking about explicit JOIN keyword or putting tables in where clause - there are benefits for both approaches and both approaches are according to standard, so I personally think that's the matter of each project - whether they like one or another syntactic type. That's more matter of taste :) I’ve tried to summarize various join types here http://www.gplivna.eu/papers/sql_join_types.htm
I’d like to add that natural join syntax is very dangerous and actaully asks for trouble as soon as table structure changes.
Speaking about join criteria vs filter criteria – it doesn’t really matter for inner joins where these are written. However for outer joins it really does matter where another criteria are written – result changes – see chapter 6.4 Difference between predicates in ON clause vs. predicates in WHERE clause in my article.
And speaking cross join vs inner join – the biggest problem is that MySQL had mixed them up, and historically cannot probably so easy enforce cross join like real cartesian join raising error when on clause is applied and inner join like normal inner join. I think the situation is the same like old outer join operators in Oracle (+) or MS SQL (*= and =*).
And speaking about explicit JOIN keyword or putting tables in where clause – there are benefits for both approaches and both approaches are according to standard, so I personally think that’s the matter of each project – whether they like one or another syntactic type. That’s more matter of taste :)

]]> By: Toby http://www.pythian.com/news/1116/good-sql-querying/#comment-234990 Toby Sat, 12 Jul 2008 13:40:19 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-234990 Nitpicks: "performant" in your first line has a typo; but it's an ugly word, what about "faster"? Also "criteria" is plural, so "criteria where it belongs" and other cases are incorrect. Nitpicks: “performant” in your first line has a typo; but it’s an ugly word, what about “faster”? Also “criteria” is plural, so “criteria where it belongs” and other cases are incorrect.

]]> By: rudy http://www.pythian.com/news/1116/good-sql-querying/#comment-234780 rudy Sat, 12 Jul 2008 02:10:34 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-234780 thanks sheeri maybe some day i can also make you see the benefit of qualifying all columns in join queries -- after all, you're not doing it for yourself, you're doing it for whoever has to maintain the query later, eh ;o) thanks sheeri

maybe some day i can also make you see the benefit of qualifying all columns in join queries — after all, you’re not doing it for yourself, you’re doing it for whoever has to maintain the query later, eh

;o)

]]> By: Sheeri Cabral http://www.pythian.com/news/1116/good-sql-querying/#comment-234473 Sheeri Cabral Fri, 11 Jul 2008 13:20:13 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-234473 Rudy, you're absolutely correct, my apologies. The filtering queries will make it act like an INNER JOIN. This is a great example of debugging too -- you can see, because I wrote LEFT JOIN, that I intended a LEFT JOIN, so you can see my mistake. The filters such as WHERE amount>500 should be moved to the join criteria in the FROM claus. Rudy, you’re absolutely correct, my apologies. The filtering queries will make it act like an INNER JOIN. This is a great example of debugging too — you can see, because I wrote LEFT JOIN, that I intended a LEFT JOIN, so you can see my mistake. The filters such as WHERE amount>500 should be moved to the join criteria in the FROM claus.

]]> By: Rishi Agarwal http://www.pythian.com/news/1116/good-sql-querying/#comment-234399 Rishi Agarwal Fri, 11 Jul 2008 11:54:13 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-234399 Hi, Nice post. Completely agree with you on the part about " join criteria vs. filter criteria ". Thats the main reason I shifted from using "comma joins" to " left/right/inner join" and this has changed the way I think and write queries. Hi, Nice post. Completely agree with you on the part about ” join criteria vs. filter criteria “. Thats the main reason I shifted from using “comma joins” to ” left/right/inner join” and this has changed the way I think and write queries.

]]> By: Roland Bouman http://www.pythian.com/news/1116/good-sql-querying/#comment-234243 Roland Bouman Fri, 11 Jul 2008 08:14:20 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-234243 Hi Sheeri! nice post. Few comments: "There is no such thing as a “comma join”, really what you mean is an “inner join” or a “left/right join” or “cross join” (or “natural join”)." This suggests that NATURAL JOIN is a proper type. It is not, you can have inner and outer NATURAL joins. I don't regard LEFT/RIGHT as different types either - it's just syntax, there is not difference in the concept. So, I end up with three proper join types: cross join, inner join, outer join. (I don't write caps now because I'm referring to the concepts - not the actual syntax). One of the things I expected you'd write about is LEFT vs RIGHT joins. Personally I always only use LEFT - never RIGHT. It doesn't really matter which one you use but I really don't see the point of using both. "Now, an example where it really helped me to debug when the query was written in “good” format (note that this no longer uses the sakila sample database):" In MySQL 5.1 and MySQL 5.0 you get a syntax error when you leave out the ON clause for LEFT and RIGHT join (insanely enough, not for INNER JOIN). So I don't see what how the formatting could've helped there. Your remark about "join criteria" vs "filter criteria" is nice and I tend to think about it that way too. That is to say, I used to call all conditions that relate tables by comparing their columns as the 'join condition'. It turns out you can't really rigorously define it. consider SELECT City.Name, Country.Name, Country.IndepYear FROM City LEFT JOIN Country ON City.ID = Country.Capital AND Country.IndepYear IS NOT NULL WHERE City.Name IN ('Kabul', 'Oranjestad', 'Qandahar') (“all cities, and if they are the capital of an independent country, the country name and year of independence”) Here "Country.IndepYear IS NOT NULL" does not realy relate a city to a country, it is more like an extra condition to be applied when matching capital cities to their country. We can't move it to the WHERE clause, as that would change the meaning of the query (effectively turning it into an inner join of "all capital cities of independent countries") So, what are we to call this "Country.IndepYear IS NOT NULL" part? The only sensible thing I can think of is to call the entire thing City.ID = Country.Capital AND Country.IndepYear IS NOT NULL the join condition, and not make any judgment of the nature of the expression. (although I still feel that for inner joins it is best to keep the 'filtering' ones separate from the 'join' ones, but it's just a habit.) kind regards, Roland Hi Sheeri!

nice post. Few comments:

“There is no such thing as a “comma join”, really what you mean is an “inner join” or a “left/right join” or “cross join” (or “natural join”).”

This suggests that NATURAL JOIN is a proper type. It is not, you can have inner and outer NATURAL joins. I don’t regard LEFT/RIGHT as different types either – it’s just syntax, there is not difference in the concept. So, I end up with three proper join types: cross join, inner join, outer join. (I don’t write caps now because I’m referring to the concepts – not the actual syntax).

One of the things I expected you’d write about is LEFT vs RIGHT joins. Personally I always only use LEFT – never RIGHT. It doesn’t really matter which one you use but I really don’t see the point of using both.

“Now, an example where it really helped me to debug when the query was written in “good” format (note that this no longer uses the sakila sample database):”

In MySQL 5.1 and MySQL 5.0 you get a syntax error when you leave out the ON clause for LEFT and RIGHT join (insanely enough, not for INNER JOIN). So I don’t see what how the formatting could’ve helped there.

Your remark about “join criteria” vs “filter criteria” is nice and I tend to think about it that way too. That is to say, I used to call all conditions that relate tables by comparing their columns as the ‘join condition’. It turns out you can’t really rigorously define it.
consider

SELECT City.Name, Country.Name, Country.IndepYear
FROM City LEFT JOIN Country
ON City.ID = Country.Capital
AND Country.IndepYear IS NOT NULL
WHERE City.Name IN (‘Kabul’, ‘Oranjestad’, ‘Qandahar’)

(“all cities, and if they are the capital of an independent country, the country name and year of independence”)

Here “Country.IndepYear IS NOT NULL” does not realy relate a city to a country, it is more like an extra condition to be applied when matching capital cities to their country. We can’t move it to the WHERE clause, as that would change the meaning of the query (effectively turning it into an inner join of “all capital cities of independent countries”)

So, what are we to call this “Country.IndepYear IS NOT NULL” part? The only sensible thing I can think of is to call the entire thing

City.ID = Country.Capital AND Country.IndepYear IS NOT NULL

the join condition, and not make any judgment of the nature of the expression.

(although I still feel that for inner joins it is best to keep the ‘filtering’ ones separate from the ‘join’ ones, but it’s just a habit.)

kind regards,

Roland

]]> By: Carsten Pedersen http://www.pythian.com/news/1116/good-sql-querying/#comment-234239 Carsten Pedersen Fri, 11 Jul 2008 08:02:26 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-234239 Great post Sheeri, and the number of comments certainly shows that you hit a nerve :-) Agree with everything you say, and very happy that you also took time to mention USING .. way too many people are unaware of just how powerful that is, not only when writing it but also in helping someone understand what's going on when they read the query 6 months from now. My personal addition would be a rant about those people that insist on aliasing every single table and column with a shorthand name, because "it makes it easier to understand and write". Great post Sheeri, and the number of comments certainly shows that you hit a nerve :-)

Agree with everything you say, and very happy that you also took time to mention USING .. way too many people are unaware of just how powerful that is, not only when writing it but also in helping someone understand what’s going on when they read the query 6 months from now.

My personal addition would be a rant about those people that insist on aliasing every single table and column with a shorthand name, because “it makes it easier to understand and write”.

]]> By: Arjen Lentz http://www.pythian.com/news/1116/good-sql-querying/#comment-233953 Arjen Lentz Fri, 11 Jul 2008 01:18:34 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-233953 And for optimum evil, try NATURAL [INNER|LEFT|RIGHT] JOIN. Unless there is a very strict and sane identifier naming rule in place with the schema design, it'll break things in oh so many ways at a future time you won't expect ;-) And for optimum evil, try NATURAL [INNER|LEFT|RIGHT] JOIN.
Unless there is a very strict and sane identifier naming rule in place with the schema design, it’ll break things in oh so many ways at a future time you won’t expect ;-)

]]> By: rudy http://www.pythian.com/news/1116/good-sql-querying/#comment-233938 rudy Fri, 11 Jul 2008 00:31:23 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-233938 if, for a specific day, there is no matched row in the sales table, then the columns in the intermediate result produced by the LEFT OUTER JOIN that would've come from the sales table will be NULL, right? i mean, that's how a LEFT OUTER JOIN works so what happens in the WHERE clause? one of those columns has to be greater than 500, and another of those columns has to be equal to 'paid' NULL is not greater than anything, and NULL is not equal to anything therefore, all the unmatched rows will be filtered out in effect, it's an inner join unless, of course, "amount" and "type" are actually in the day_tbl ;o) if, for a specific day, there is no matched row in the sales table, then the columns in the intermediate result produced by the LEFT OUTER JOIN that would’ve come from the sales table will be NULL, right? i mean, that’s how a LEFT OUTER JOIN works

so what happens in the WHERE clause? one of those columns has to be greater than 500, and another of those columns has to be equal to ‘paid’

NULL is not greater than anything, and NULL is not equal to anything

therefore, all the unmatched rows will be filtered out

in effect, it’s an inner join

unless, of course, “amount” and “type” are actually in the day_tbl ;o)

]]> By: Justin Swanhart http://www.pythian.com/news/1116/good-sql-querying/#comment-233925 Justin Swanhart Fri, 11 Jul 2008 00:12:34 +0000 http://www.pythian.com/blogs/1116/good-sql-querying#comment-233925 I find, that if I want to use a reserved word for a table, pluralizing that word often works out well. days and dates for example I find, that if I want to use a reserved word for a table, pluralizing that word often works out well.

days and dates for example

]]>