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
Related
I'm hoping some of the more experienced database/dwh developers or DBAs can weigh in on this one:
My team is using OBIEE as a front-end tool to drive ad-hoc reporting being done by our business units.
There is a lot of latency when generating sets that are relatively small. We are facing ~1 hour to produce ~50k records.
I looked into one of the queries that is behaving this way, and I was surprised to find that all of the tables being referenced are being cross-joined, and then filters are being applied in the WHERE clause.
So, to illustrate, the queries tend to look like this:
SELECT ...
FROM tbl1
,tbl2
,tbl3
,tbl4
WHERE tbl1.col1 = tbl2.col1
and tbl3.col2 = tbl2.col2
and tbl4.col3 = tbl3.col3
instead of like this:
SELECT ...
FROM tbl1
INNER JOIN tbl2
ON tbl1.col1 = tbl2.col1
INNER JOIN tbl3
ON tbl3.col2 = tbl2.col2
INNER JOIN tbl4
ON tbl4.col3 = tbl3.col3
Now, from what I know about the order of query operations, the FROM clause gets performed before the WHERE clause, so the first example would perform much more slowly than the latter example. Am I correct (please answer only if you know the answer in the context of Oracle DB)? Unfortunately, I don't have the admin rights to run a trace against the 2 different versions of the query.
Is there a reason to set up the query the first way, related to how the OBIEE interface works? Remember, the query is the result of a user drag-and-dropping attributes into a sandbox, from a 'bank' of attributes. Selecting any combination of the attributes is supposed to generate output (if the data exists). The attributes come from many different tables. I don't have any experience in designing the mecahnism that generates the SQL based on this kind of ad-hoc attribute selection, so I don't know whether the query design in the first example is required to service this kind of reporting tool.
Don't worry, historically Oracle used the first notation for inner joins but later on adopted ANSI SQL standards.
The results in terms of performance and returned recordsets are exactly the same, the implicit 'comma' joins are not crossing resultset but effectively integrating the WHERE filters. If you doubt it, run an EXPLAIN SELECT command for both queries and you will see the forcasted algorithms will be identical.
Expanding this answer you may notice in the future the analogous notation (+) in place of outer joins. This answer will also stand correct in that context.
The real issue comes when both notations (implicit and explicit joins) are mixed in the same query. This would be asking for trouble big time, but I doubt you find such a case in OBIEE.
Those are inner joins, not cross joins, they just use the old syntax for doing it rather than ANSI as you were expecting.
Most join queries contain at least one join condition, either in the FROM clause or in the WHERE clause. (Oracle Documentation)
For a simple query such as in your example the execution should be exactly the same.
Where you have set outer joins (in the business model join) you will see OBI produce a query where the inner joins are made in the WHERE clause and the outer joins are done ANSI in the FROM statement – just to make things really hard to debug!
SELECT ...
FROM tbl1
,tbl2
,tbl3 left outer join
tbl4 on tbl3.col1 = tbl4.col2
WHERE tbl1.col1 = tbl2.col1
and tbl3.col2 = tbl2.col2
and tbl4.col3 = tbl3.col3
This question already has answers here:
Oracle Joins - Comparison between conventional syntax VS ANSI Syntax
(11 answers)
Closed 9 years ago.
I have come across many websites to find the answer about which one is better, ANSI or non- ANSI syntax. What is the difference between these two queries?
select a.name,a.empno,b.loc
from tab a, tab b
where a.deptno=b.deptno(+);
and:
select a.name,a.empno,b.loc
from tab a
left outer join tab b on a.deptno=b.deptno;
The result is same in both the cases. The second query is also longer. Which one is better?
suppose if we have added another table Salgrade in the above query based on what conditions we need to join them?? ..
can any one assume one table and give me explanation
both syntaxes usually work without problems, but if you try to add a where condition you will see that with the second one is much simpler to understand which is the join condition and which is the where clause.
1)
SELECT a.name,
a.empno,
b.loc
FROM tab a,
tab b
WHERE a.deptno = b.deptno(+)
AND a.empno = 190;
2)
SELECT a.name,
a.empno,
b.loc
FROM tab a,
LEFT OUTER JOIN tab b
ON a.deptno = b.deptno
WHERE a.empno = 190;
Also, it's much easier to recognize an outer join and do not forget to include the (+). Overall you can say it's just a question of taste, but the truth is that the second syntax is much more readable and less prone to errors.
The first is a legacy Oracle specific way of writing joins, the second is ANSI SQL-92+ standard and is the preferred one.
Extensively discussed many a times, including one by me.
Use explicit JOINs rather than implicit (regardless whether they are outer joins or not) is that it's much easier to accidently create a cartesian product with the implicit joins.
With explicit JOINs you cannot "by accident" create one. The more tables are involved the higher the risk is that you miss one join condition.
Basically (+) is severely limited compared to ANSI joins. Furthermore it is only available in Oracle whereas the ANSI join syntax is supported by all major DBMS
SQL will not start to perform better after migration to ANSI syntax - it's just different syntax.
Oracle strongly recommends that you use the more flexible FROM clause join syntax shown in the former example. In the past there were some bugs with ANSI syntax but if you go with latest 11.2 or 12.1 that should be fixed already.
Using the JOIN operators ensure your SQL code is ANSI compliant, and thus would allow a front-end application to be more easily ported for other database platforms.
Join conditions have a very low selectivity on each table and a high selectivity on the tuples in the theoretical cross product. Conditions in the where statement usually have a much higher selectivity.
Oracle internally converts ANSI syntax to the (+) syntax, you can see this happening in the execution plan's Predicate Information section.
If you are using 11.2 I advise ANSI join. If you use 12C, there are some new bugs unearthed on OUTER JOINS.
I also remember some bugs in Oracle while using ANSI syntax, before 11.2 where it got fixed in 11.2.
In my opinion, I am not a big fan of ANSI syntax, though Oracle does confirm to the standards of ANSI, it is not totally bug free.
please, read this article about joins.
result of your example is not same, if you have data in B table and not in A table
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.
First option:
SELECT Table1.* ,Table2.Price AS Price
FROM
Table1,Table2
WHERE
Table1.ID = Table2.ID
Second option:
SELECT Table1.* ,Table2.Price AS Price
FROM
Table1 INNER JOIN Table2 ON Table1.ID = Table2.ID
Which one is better and most efficient?
It may give you the same results, however the second option is better because it follows the latest standards, and properly defines what is the join and what may be a where clause. In terms of performance the two statements as above should perform the same.
The second way does the same thing, only with ANSI (American National Standards Institute standardized Structured Query Language) SQL, a standard form of SQL. Research it further to find its pros and cons.
http://it.toolbox.com/blogs/oracle-experience/a-case-for-ansi-sql-15647
They're both joins, the first is just using the implicit syntax and the second is using the explicit syntax.
Tons of duplicate questions
Also, it should be covered in any decent SQL book (I've got my understanding of the question from the O'Reilly pocket reference). Also, I still wonder where people get the old syntax examples, maybe I just learned SQL from the good sources. Also, while people repeat that both variants produce the same query with the same performance, I still prefer to doubt that when the talk is not about some DBMS specifically stating that in its documentation and especially when the talk is about DBMS in general.
the first query join style uses ancient join syntax, while the second style is more current. In most cases they result in the exact same query execution plan. However when using LEFT AND RIGHT OUTER JOINS, you can have probelms, see this answer and the comments:
ANSI joins versus "where clause" joins
from SQL Server BOL(2000) "In earlier
versions of Microsoft® SQL Server™
2000 left and right outer join
conditions were specified in the WHERE
clause using the *= and =*
operators. In some cases, this syntax
results in an ambiguous query that can
be interpreted in more than one way.
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.