Is there any support for natural joins in recent Microsoft SQL Server editions? Or is there a good alternative for making SQL Server work out the predicates that would have been in the ON clauses based on the referential integrity?
No, and thank the lucky stars
I can't believe that you'd want the engine to guess the JOIN for you
Related links:
SQL Server - lack of NATURAL JOIN / x JOIN y USING(field)
is NATURAL JOIN any better than SELECT FROM WHERE in terms of performance ?
Edit, to explain why
The JOIN (whether USING or ON) is clear and explicit
I should be able to name my columns for the entity stored in the table, without worrying about what a column is called in another table, without NATURAL JOIN side effects
Quoting Bill Karwin in this excellent answer:
I never use NATURAL JOIN because I don't like the possibility that the
join could do something I don't intend just because some column name
exists in both tables.
MS SQL does not support natural join, neither join using (). You have to explicitly write down all your attributes used in the join.
If the datamodel changes, you have to change all "natural join" written by hand and make sure your join condition is ok again.
I wouldn't expect to see it any time soon. A Connect suggestion from 2006 has very little info other than:
Thanks for your feedback. We will look into your request for one of the upcoming releases.
And has only received ~30 upvotes
use Full Outer join instead of Natural Join. It works for me.
Related
I have a table "Price" that should be filtered according to a value stored in an another table "CutPrice" (meaning only prices inferior to the parameter stored should be displayed).
I experimented various way, and for a laugh I did the following:
SELECT Location, Price, CutoffPrice
FROM LocPrice INNER JOIN
CutPrice ON CutPrice.CutOffPrice < LocPrice.Price
Using the inferior than sign works perfectly, it's even faster than the Case statement I used in another version of the query.
I try googling for it, to see if it's standard, recommended, not recommended, even a bug , perhaps ?
I could not find anything. So I know, the question might be a bit broad for the site, but is this a standard use of JOINS or is there anything to be careful about when using this ? Particularly about T-SQL on SQL server 2005
Non-equi joins are a pretty standard part of SQL. See http://blog.mclaughlinsoftware.com/oracle-sql-programming/basic-sql-join-semantics/ for example. Most of the major databases support non-equi joins, usually with both SQL 92 JOIN ON syntax and pre-SQL 92 WHERE syntax. However, if you have a particular database in mind searching for 'non-equi join <db name>' will usually find mention of it doesn't support them, e.g. Hive: work around for non equi left join
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Is there something wrong with joins that don't use the JOIN keyword in SQL or MySQL?
Hi,
i'ave always retrieved data without joins...
but is there a benefit to one method over the other?
select * from a INNER JOIN b on a.a = b.b;
select a.*,b.* from a,b where a.a = b.b;
Thanks!
The first method using the INNER JOIN keyword is:
ANSI SQL standard
much cleaner and more expressive
Therefore, I always cringe when I see the second option used - it just bloats up your WHERE clause, and you can't really see at one glance how the tables are joined (on what fields).
Should you happen to forget one of the JOIN conditions in a long list of WHERE clause expressions, you suddenly get a messy cartesian product..... can't do that with the INNER JOIN keyword (you must express what field(s) to join on).
I'd say the biggest benefit is readability. The version with the explicitly named join types are much easier for me to comprehend.
You are using a different syntax for a JOIN, basically. As a matter of best practices, it is best to use the first syntax (explicit JOIN) because it is clearer what the intention of the query is and makes the code easier to maintain.
These are both joins. they are just two different syntactical representations for joins. The first one, (using the "Join" keyword, is the current ANSI Standard (as of 1992 I think).
In the case of inner joins only, the two differeent representations are functionally identical, but the latter ANSI SQL92 standard syntax is much moire readable, once you get used to it, because each individual join condition is associated with the pair of intermediate resultsets being joined together, In the older representation, the join conditions are all together, along with the overall queries' filter conditions, in the where clause, and it is not as clear which is which. This makes identifying bad join conditions (where for example, an unintended cartesian product will be generated) much more difficult.
But more important, perhaps, is that, when performing an outer Join, in certain scenarios, the older syntax is NOT equivilent, and in fact will generate the WRONG resultset.
You should transition to the newer syntax for all your queries.
You've always retrieved the data with joins. The second query is using old syntax, but in the background it is still join :)
This depends on the RDBMS but in the case of SQL server I understand that the utilizing the former syntax allows for better optimization. This is less of a SQL question and more of a vendor specific question.
You can also use the EXPLAIN (SQL Server: Query Execution Plan) type functions to help you understand if there is a difference. Each query is unique and I imagine that the stored statistics can (and will) alter the behavior.
I'm creating a query that will display information for a record which is derived from 8 tables. The developer who originally wrote the query used a combination of 'where this equals this' AND 'this equals this' to create the joins.
I have since changed the query to use INNER JOINS. I wondered if my approach was better than utilising a combination of WHERE operators.
On a measure of good practice, is a combination of INNER JOINS a good option or should I be employing a different technique.
From performance point of view, there will not be any difference... atleast not on prominent RDBMS like Sql-server / Oracle... These Database Engine, are capable of identifying both the patterns means the same and use the same execution plan for both...
In my humble opinion both are equally good practice, but you should maintain consistency and proper alignment... Somewhere I heard that where clause are generally used by oracle developers, and inner join by Sql-Server... Not very much sure about that... By now most of the coders are capable of understanding both types of queries...
I beleive that there is no performance difference between both :
ANSI Style
SELECT * FROM Table1 a JOIN TABLE2 b on a.id = b.id
Old Style
SELECT * FROM Table1 a , TABLE2 b
WHERE a.id = b.id
The ANSI style is newer and more readable and pretty, i do prefer the old style especially when it comes to join more than 4/5 Tables... maybe because im an Oracle Dev as it was said before o_O
Both will behave the same (as The King said). Personally I prefer the INNER/OUTER/LEFT JOIN syntax because its more intuitive/explicit. When you get into LEFT JOINs with join conditions in the WHERE clause then you have to get into using plus signs and then you have to remember which side to put them on. Urgghh.
It also seems (again as The King said) to be true that Oracle devs favour putting the join conditions into the WHERE clause.
-Jamiet
I've just been reading up on NATURAL JOIN / USING - SQL92 features which are (sadly?) missing from SQL Server's current repertoire.
Has anyone come from a DBMS that supported these to SQL Server (or another non-supporting DBMS) - were they as useful as they sound, or a can of worms (which also sounds possible!)?
I never use NATURAL JOIN because I don't like the possibility that the join could do something I don't intend just because some column name exists in both tables.
I do use the USING join syntax occasionally, but just as often it turns out that I need a more complex join condition than USING can support, so I convert it to the equivalent ON syntax after all.
Would you consider a DBMS that was truly relational?:
in Tutorial D [a truly relational
language], the only “join” operator is
called JOIN, and it means “natural
join”... There should be no other kind
of join... Few people have had the
experience of using a proper
relational language. Of those who
have, I strongly suspect that none of
them ever complained about some
perceived inconvenience in pairing
columns according to their names
Source: "The Importance of Column Names" by Hugh Darwen
It's a matter of convenience. Not indispensable, but it should have its place, for example in interactive querying (every keystroke brings us closer to RSI, anyway), or some simple cases of hand written SQL even in production code (yes, I wrote that. And even seen JOIN USING in serious code, written by wise programmers other than myself. But, I'm digressing).
I found this question when looking for confirmation that SS is missing this feature, and I got it. I am only bewildered by the amount of hate against this syntax, which I attribute to the Sour Grapes Syndrome. I feel amused when being lectured with a patronising tone Sweets (read: syntactic sugar) is bad for your health. You don't need it anyway.
What is nice in the JOIN USING syntax, is that it works not just on column names, but also on column aliases, for example:
-- foreign key "order".customerId references (customer.id)
SELECT c.*, c.id as customerId, o.* from customer c
join "order" o using (customerId);
I don't agree with "Join using would be better, if only (...)". Or the argument, that you may need more complex conditions. From a different point of view, why use JOIN ON? Why not be pure, and move all conditions to the WHERE clause?
SELECT t1.*, t2.* from t1, t2 where t2.t1_id = t1.id;
I could now go mad and argue, how this is the cleanest way to express a join, and you can immediately start adding more conditions in the where clause, which you usually need anyway, blah blah blah...
So you shouldn't miss this particular syntax too dearly, but there's nothing to be happy about for not having it ("Phew, that was close. So good not to have JOIN USING. I was spared a lot of pain").
So, while I personally use JOIN ON 99% of the time, I feel no Schadenfreude when there is no JOIN USING or NATURAL JOIN.
I don't see the value of the USING or NATURAL syntax - as you've encountered, only ON is consistently implemented so it's best from a portability standpoint.
Being explicit is also better for maintenance, besides that the alternatives can be too limited to deal with situations. I'd also prefer my codebase be consistent.
EDIT 9-3-10: I found this blog entry recently that was very enlightening. http://optimizermagic.blogspot.com/2007/12/outerjoins-in-oracle.html
There are times when one or the other join syntax may in fact perform better. I have also found times when a have noticed a slight performance increase (only noticeable in VLDBs) when choosing the Oracle join syntax over the ANSI one. Probably not enough to get fussy over, but for those serious about mastering the Oracle DB, it may be helpful to review the article.
I am aware of two outer join syntaxes for Oracle:
select a, b
from table1
left outer join table2
on table2.foo = table1.foo
OR
select a, b
from table1, table2
where table2.foo(+) = table1.foo
(assuming I got the syntax of the second sample right.)
Is there a performance difference between these? At first I thought it must just be a style preference on the part of the developer, but then I read something that made me think maybe there would be a reason to use one style instead of the other.
"maybe there would be a reason to use
one style instead of the other. "
There are reasons, but not performance related ones. The ANSI style outer joins, as well as being standard, offer FULL OUTER JOINs and outer joins to multiple tables.
Oracle didn't support ANSI syntax prior to version 9i.
Since that version, these queries do the same and yield the same plan.
Correct pre-9i syntax is this:
SELECT a, b
FROM table1, table2
WHERE table2.foo(+) = table1.foo
There is no performance difference. You can also check the execution plans of both queries to compare.
Theoretically, the second query performs the Cartesian product of the two tables and then selects those meeting the join condition. In practice, though, the database engine will optimize it exactly the same as the first.
I found some additional information in answer to my own question. Looks like the old style is very limiting, as of this doc from 3 years ago.
http://www.freelists.org/post/oracle-l/should-one-use-ANSI-join-syntax-when-writing-an-Oracle-application,2
I think perhaps it would only make sense to use the old style if for some reason the queries might be run on an outdated version of Oracle.
The stuff I see at work is almost all in the old style, but it's probably just because the consultants have been working in Oracle since before 9i and they likely didn't see a reason to go update all the old stuff.
Thanks all!
It's not the same. In the first case you're forcing to join the tables in that order.
In the second case Oracle Planner can choose the best option to execute the query.
In this trivial case the result probably will be the same in all the executions, but if you use that syntax in more complex cases the difference will be shown.