Unfortunately, I don't have access to an Ingres database at the moment and I'm just wondering if the inner join syntax that applies in standard SQL also applies in Ingres?
I'm also wondering about the equivalent to inner join.
For instance, are the following two SQL statements valid?
Statement 1:
SELECT a.Value1,
a.Value2,
b.Value3
FROM Tabletype1 a, Tabletype2 b, Tabletype3 c
WHERE a.Value1 = b.Value4
AND b.Tabletype3_Num = c.Tabletype3_Num
AND p.Value5 = 'Randomvalue'
AND b.Value3 > 20
AND (a.Tabletype1Format = 'Random' OR a.Tabletype1Format = 'Random1')
Statement 2:
SELECT a.Value1,
a.Value2,
b.Value3
FROM Tabletype1 a
INNER JOIN Tabletype2 b
ON a.Value1 = b.Value4
INNER JOIN Tabletype3 c
ON b.Tabletype3_Num = c.Tabletype3_Num
WHERE c.Value5 = 'Randomvalue'
AND b.Value3 > 20
AND (a.Tabletype1Format = 'Random' OR a.Tabletype1Format = 'Random1')
In response to the question the OP actually asked, Ingres absolutely, for sure, definitely does fully support BOTH forms of join specification, and in every case I have ever bothered to look at, it comes up with exactly the same query plan.
So my bottom line answer is do what you think is preferable in your situation. It will work fine.
Both forms work fine in Ingres, although you would appreciate the SQL92 ANSI syntax is more preferable for
readability
clarity
to help the query optimizer know where the join really happens
This question is very similar to SQL Inner Join syntax
Related
I am running simple select script, which inner join with other 3 table . all the tables are big ( lots of data ) its taking around 20 sec to run. want to optimized it.
I tried to used nolock , but not much deference
SELECT RR.ReportID,
RR.RequestFormat,
RRP.SequenceNumber,
RRP.ParameterName,
RRP.ParameterValue
CASE WHEN RP.ParameterLabelOvrrd IS NULL THEN P.ParameterLabel ELSE .ParameterLabelOvrrd END AS ParameterLabelChosen,
RRP.ParameterValueEntered
FROM ReportRequestParameters AS RRP WITH (NOLOCK)
INNER JOIN ReportRequests AS RR WITH (NOLOCK) ON RRP.RequestID = RR.RequestID
INNER JOIN ReportParameter AS RP WITH (NOLOCK) ON RP.ReportID = RR.ReportID
AND RP.SequenceNumber = RRP.SequenceNumber
INNER JOIN Parameter AS P WITH (NOLOCK) ON P.ParameterID = RP.ParameterID
WHERE RRP.RequestID = '2226765'
ORDER BY SequenceNumber;
Please advice.
This is your query:
SELECT RR.ReportID, RR.RequestFormat, RRP.SequenceNumber,
RRP.ParameterName, RRP.ParameterValue
COALESCE(RP.ParameterLabelOvrrd, P.ParameterLabel) as ParameterLabelChosen,
RRP.ParameterValueEntered
FROM ReportRequestParameters RRP JOIN
ReportRequests RR
ON RRP.RequestID = RR.RequestID JOIN
ReportParameter RP
ON RP.ReportID = RR.ReportID AND
RP.SequenceNumber = RRP.SequenceNumber JOIN
Parameter P
ON P.ParameterID = RP.ParameterID
WHERE RRP.RequestID = 2226765
ORDER BY RRP.SequenceNumber;
I have removed the single quotes on 2226765, assuming that the id is a number. Mixing types can impede the optimizer.
Then, I recommend an index on ReportRequestParameters(RequestID, SequenceNumber). I assume the other tables have indexes on the appropriate columns, but these are:
ReportRequests(RequestID, ReportID, SequenceNumber)
ReportParameter(ReportID, SequenceNumber, ParameterID)
Parameter(ParameterID)
I strongly advise you not to use nolock, unless you know what you are doing. Aaron Bertrand has a good blog post on this subject.
I would suggest running with the execution plan turned on and see if SSMS can advise you on additional indexing.
Other than that your query looks straight-forward, nothing code wise that is going to help make it faster, other than perhaps getting rid of the case statement and definitely getting rid of the NOLOCK statements.
I need to convert a legacy SQL outer Join to ANSI.
The reason for that being, we're upgrading from a legacy DB instance (2000/5 ?) to SQL 2016.
Legacy SQL query :-
SELECT
--My Data to Select--
FROM counterparty_alias ca1,
counterparty_alias ca2,
counterparty cp,
party p
WHERE cp.code *= ca1.counterparty_code AND
ca1.alias = 'Party1' AND
cp.code *= ca2.counterparty_code AND
ca2.alias = 'Party2' AND
cp.code *= p.child_code AND
cp.category in ('CAT1','CAT2')
Here, Party1 and Party2 Are the party type codes and CAT1 and CAT2 are the category codes. They're just data; I have abstracted it, because the values don't really matter.
Now, when I try to replace the *= with a LEFT OUTER JOIN, I get a huge mismatch on the Data, both in terms of the number of rows, as well as the Data itself.
The query I'm using is this :
What am I doing wrong ?
SELECT
--My Data to Select--
FROM
counterparty cp
LEFT OUTER JOIN counterparty_alias ca1 ON cp.code = ca1.counterparty_code
LEFT OUTER JOIN counterparty_alias ca2 ON cp.code = ca2.counterparty_code
LEFT OUTER JOIN party p ON cp.code = p.child_code
WHERE
ca1.alias = 'Party1' AND
ca2.alias = 'Party2' AND
cp.category in ('CAT1','CAT2')
Clearly , in all the three legacy joins , the cp (counterparty) table is on the Left hand Side of the *=. So that should translate to a LEFT OUTER JOIN WITH all the three tables. However, my solution doesn't seem to to be working
How can I fix this ? What am I doing wrong here ?
Any help would be much appreciated. Thanks in advance :)
EDIT
I also have another query like this :
SELECT
--My Data to Select--
FROM dbo.deal d,
dbo.deal_ccy_option dvco,
dbo.deal_valuation dv,
dbo.strike_modifier sm
WHERE d.deal_id = dvco.deal_id
AND d.deal_id = dv.deal_id
AND dvco.base + dvco.quoted *= sm.ccy_pair
AND d.maturity_date *= sm.expiry_date
In this case, both the dvco and d tables seem to be doing a LEFT OUTER JOIN on the same table sm. How do I proceed about this ?
Maybe join in on the same table and use an alias sm1 and sm2 ?
Or should I use sm as the central table and change the join to RIGHT OUTER JOIN on dvco and d tables ?
I think the problem with your translation is that you are using conditions on the right tables in the where clause instead of in the on clause.
When I tried to translate it, this is the translation I've got:
FROM counterparty cp
LEFT JOIN counterparty_alias ca1 ON cp.code = ca1.counterparty_code
AND ca1.alias = 'Party1'
LEFT JOIN counterparty_alias ca2 ON cp.code *= ca2.counterparty_code
AND ca2.alias = 'Party2'
LEFT JOIN party p ON cp.code = p.child_code
WHERE cp.category in ('CAT1','CAT2')
However, it's hard to know if I'm correct since you didn't provide sample data, desired results, or even a complete query.
If you're doing a conversion, it has been my experience that *= is a RIGHT OUTER JOIN and =* is a LEFT OUTER JOIN in terms of a straight conversion.
I am converting hundreds of stored procs and views now and through testing this is what matches. I run the query as the original first, then make the changes and re-run it with the ANSI compliant code.
The data returned needs to be the same for consistency in our application.
So for your second query I think it would look something like this:
FROM dbo.deal d
INNER JOIN dbo.deal_ccy_option dvco ON d.deal_id = dvco.deal_id
INNER JOIN dbo.deal_valuation dv ON d.deal_id = dv.deal_id
RIGHT OUTER JOIN dbo.strike_modifier sm ON d.maturity_date = sm.expiry_date
AND (dvco.base + dvco.quoted) = sm.ccy_pair
Thanks for the help and sorry for the late post, but I got it to work with a quick hack, using the Query Designer Tool inbuilt in SSMS. It simply refactored all my queries and put in the correct Join, Either Left or Right , and the Where condition as an AND condition on the Join itself, so I was getting the correct data result set for both pre and post, only sometimes the data sorting/ordering was a little off.
I got lost with deadlines and couldnt update with the solution earlier. Thanks again for the help. Hope this helps someone else too !!
Still a little bit unsure though why the ordering/sorting was a little off if the Join condition was the same and the filters as well, because data was a 100 % match.
To get the query Designer to Work , just select your legacy SQL, and
open the Query Designer by pressing Ctrl + Shift + Q or Goto Main Menu
ToolBar => Query => Design Query in Editor.
Thats it. This will refactor your legacy code to new ANSI standards. You wll get the converted query with the new Joins that you can copy and test. Worked 100% of the time for me, except in some cases where the sorting was not matching, which you can check by adding a simple order by clause to both pre and post to compare the data.
For reference, I cross checked with this post :
http://sqlblog.com/blogs/john_paul_cook/archive/2013/03/02/using-the-query-designer-to-convert-non-ansi-joins-to-ansi.aspx
I have 2 sql queries one of them work but the other gives error. Following query works well
select /*ordered*/ coupon_address.coupon,merchant_address.id
from merchant_address,
coupon_address,
customers c
WHERE merchant_address.id = coupon_address.merchant_address
and c.CUSTOMER_ID = 'temp1'
AND sdo_within_distance(c.cust_geo_location,merchant_address.store_geo_location,'distance = 1 unit=MILE') = 'TRUE';
But following query doesn't work and gives an error
select /*ordered*/ coupon_address.coupon,merchant_address.id
from coupon_address,
customers c
JOIN merchant_address ON merchant_address.id=coupon_address.merchant_address
WHERE c.CUSTOMER_ID = 'temp1'
AND sdo_within_distance (c.cust_geo_location,merchant_address.store_geo_location, 'distance = 1 unit=MILE') = 'TRUE';
Error is
ERROR at line 1: ORA-00904: "COUPON_ADDRESS"."MERCHANT_ADDRESS": invalid identifier
Don't ever mix explicit and implicit join syntax together! They will always lead to confusion and errors :
select /*ordered*/ coupon_address.coupon,merchant_address.id
FROM coupon_address
JOIN merchant_address
ON merchant_address.id=coupon_address.merchant_address
JOIN customers c ON c.CUSTOMER_ID = 'temp1'
WHERE sdo_within_distance (c.cust_geo_location,
merchant_address.store_geo_location,
'distance = 1 unit=MILE') = 'TRUE';
The reason it didn't work is the order that the parser evaluates the query. Probably the unknown column's table wasn't evaluated yet.
The JOIN has a higher precedence than the , in the FROM clause. ON is part of the JOIN so it only sees that which begin joined, including earlier joins.
So:
select /*ordered*/ coupon_address.coupon,merchant_address.id
from coupon_address,
customers c
JOIN merchant_address
ON merchant_address.id=coupon_address.merchant_address
is in essence:
select /*ordered*/ coupon_address.coupon,merchant_address.id
from coupon_address,
(customers c
JOIN merchant_address
ON merchant_address.id=coupon_address.merchant_address)
and coupon_address is not yet in scope.
As others have said, best to stick to one style of joins, either SQL-92 join keywords or the earlier commas in the from clause and join criteria in the where clause. I prefer the explicit join syntax.
Sagi's answer is correct. The reason your version doesn't work is because of the scoping rules around commas in the FROM clause. Oh, did I mention: Never use commas in the FROM clause. Always use explicit JOIN syntax.
Your FROM clause is evaluated as:
from coupon_address,
(customers c JOIN
merchant_address
ON merchant_address.id = coupon_address.merchant_address
)
I think this makes it obvious why you are getting the error.
I am busy converting a query using the old style syntax to the new join syntax. The essence of my query is as follows :
Original Query
SELECT i.*
FROM
InterestRunDailySum i,
InterestRunDetail ird,
InterestPayments p
WHERE
p.IntrPayCode = 187
AND i.IntRunCode = p.IntRunCode AND i.ClientCode = p.ClientCode
AND ird.IntRunCode = p.IntRunCode AND ird.ClientCode = p.ClientCode
New Query
SELECT i.*
FROM InterestPayments p
INNER JOIN InterestRunDailySum i
ON (i.IntRunCode = p.IntRunCode AND i.ClientCode = p.ClientCode)
INNER JOIN InterestRunDetail ird
ON (ird.IntRunCode = p.IntRunCode AND ird.IntRunCode = p.IntRunCode)
WHERE
p.IntrPayCode = 187
In this example, "Original Query" returns 46 rows, where "New Query" returns over 800
Can someone explain the difference to me? I would have assumed that these queries are identical.
The problem is with your join to InterestRunDetail. You are joining on IntRunCode twice.
The correct query should be:
SELECT i.*
FROM InterestPayments p
INNER JOIN InterestRunDailySum i
ON (i.IntRunCode = p.IntRunCode AND i.ClientCode = p.ClientCode)
INNER JOIN InterestRunDetail ird
ON (ird.IntRunCode = p.IntRunCode AND ird.ClientCode = p.ClientCode)
WHERE
p.IntrPayCode = 187
The "new query" is the one compatible with the current ANSI SQL standard for JOINs.
Also, I find query #2 much cleaner:
you are almost forced to think about and specify the join condition(s) between two tables - you will not accidentally have cartesian products in your query. If you happen to list ten tables, but only six join conditions in your WHERE clause - you'll get a lot more data back than expected!
your WHERE clause isn't cluttered with join conditions and thus it's cleaner, less messy, easier to read and understand
the type of your JOIN (whether INNER JOIN, LEFT OUTER JOIN, CROSS JOIN) is typically a lot easier to see - since you spell it out. With the "old-style" syntax, the difference between those join types is rather hard to see, buried somewhere in your lots of WHERE criteria.....
Functionally, the two are identical - #1 might be deprecated sooner or later by some query engines.
Also see Aaron Bertrand's excellent Bad Habits to Kick - using old-style JOIN syntax blog post for more info - and while you're at it - read all "bad habits to kick" posts - all very much worth it!
This two SQL statements return equal results but first one is much slower than the second:
SELECT leading.email, kstatus.name, contacts.status
FROM clients
JOIN clients_leading ON clients.id_client = clients_leading.id_client
JOIN leading ON clients_leading.id_leading = leading.id_leading
JOIN contacts ON contacts.id_k_p = clients_leading.id_group
JOIN kstatus on contacts.status = kstatus.id_kstatus
WHERE (clients.email = 'some_email' OR clients.email1 = 'some_email')
ORDER BY contacts.date DESC;
SELECT leading.email, kstatus.name, contacts.status
FROM (
SELECT *
FROM clients
WHERE (clients.email = 'some_email' OR clients.email1 = 'some_email')
)
AS clients
JOIN clients_leading ON clients.id_client = clients_leading.id_client
JOIN leading ON clients_leading.id_leading = leading.id_leading
JOIN contacts ON contacts.id_k_p = clients_leading.id_group
JOIN kstatus on contacts.status = kstatus.id_kstatus
ORDER BY contacts.date DESC;
But I'm wondering why is it so? It looks like in the firt statement joins are done first and then WHERE clause is applied and in second is just the opposite. But will it behave the same way on all DB engines (I tested it on MySQL)?
I was expecting DB engine can optimize queries like the fors one and firs apply WHERE clause and then make joins.
There are a lot of different reasons this could be (keying etc), but you can look at the explain mysql command to see how the statements are being executed. If you can run that and if it still is a mystery post it.
You always can replace join with nested query... It's always faster but lot messy...