Another point I think noteworthy is that with “using” the joined column must be enclosed in parenthesis/”()”, without them it’s an error.

ok the DBMS I play with is mysql 5.0.27 on NT.

Disclosure: there is not a single USING in any codebase I’m involved with.

in the example you gave:

select tbl1.col1, tbl2.col2, tbl3.col2, tbl4.col1
from apples as tbl1
   inner join oranges as tbl2 using(col3)
   inner join grapes as tbl3 using(col3)
   inner join peaches as tbl4 using(col3)

you say that “USING matches the specified columns from each table” but this is problematic — is it really each table?

in this case, col3 exists in all 4 tables, so does this mean that the last USING is equivalent to:

 on tbl4.col3 = tbl3.col3
and tbl4.col3 = tbl2.col3
and tbl4.col3 = tbl1.col3

and don’t get me started on NATURAL joins — what were they thinking?!!!

-Dave

What I don’t like about USING is that it makes you do one and the same thing (JOIN-ing) in two different ways (with ON and USING). It does happen quite often that you have a table that has more than one foreign key to one particular parent table, forcing you to use ON anyway (even if you use the convention of using the same column names for related tables - a convention which I don’t prefer). So I rather write all joins the same way - with ON. And indeed, the more exotic non-equi joins pose no problem at all to ON.

What I think would make the RELATE syntax interesting is that it would allow you to write the join as if it is a sentence or statement. It would allow you to code with the semantics of the relationship rather than the implementation with foreign keys.

To make this really work, you would actually need to be able to define foreign key constraints with additional role names. Something like

ALTER TABLE City
ADD CONSTRAINT city_resides_in_country
FOREIGN KEY (Country_id)
REFERENCES Country(id)
PARENT_ROLE `contains`
CHILD_ROLE `resides in`
;

There should be a unicity constraint on the name of the table, the rolename and the name of the related table. Now the join could be written like

SELECT *
FROM  Country RELATE `Contains` City

or, if you like

SELECT *
FROM  City RELATE `Resides in` Country

This would totally solve the issue of having more than one foreign key to the same parent table because the two relationships will always play other roles (if not, the design is wrong)

... left outer join tbl2 on col = col2 or col3 between col4 and col5...

But again, for many simple cases, a foreign key constraint join would make a lot of sense. I say, bring it on… another way to make things easier. I like having lots of ways to do things.

One reason NATURAL JOIN isn’t so useful for most things I do: people tend to add a TIMESTAMP column named ‘ts’ Obviously this shouldn’t be involved in a join :-)

I knew the syntax, but I don’t really like it. I am still waiting for what i think is the only sensible compact join syntax, the “foreign key constraint join”.

Read more here: Intelligent SQL JOIN syntax?