What is the ANSI-92 equivalent of the following old Informix SQL query?
select *
from categories c,
orders o,
outer (employees e, person p)
where c.categoryid = o.categoryid
and p.personid = e.id
and o.employeeid = e.id
and o.orderid = 7742
and e.term_date is NULL
I cannot seem to figure out exactly what the "outer (table1, table2)" syntax means.
Mike Burdick's answer is, I believe, essentially correct — but I'm not completely sure of that. I'd be a little more comfortable with the comparison if the query were written as:
SELECT *
FROM Categories AS C
JOIN Orders AS O ON C.CategoryID = O.CategoryID
LEFT JOIN
(SELECT * FROM
FROM Employees AS E
JOIN Person AS P ON E.ID = P.PersonID
) AS E ON O.EmployeeID = E.ID
WHERE O.OrderID = 7742
AND E.Term_Data IS NULL
The OUTER (Employees e, Person p) in the original query is an inner-join sub-query that is outer-joined to the main query, which I've made clearer in my version by using the sub-query, but I think Mike's version is OK too. My concern is that Mike's version might more nearly equivalent to this (where the parentheses around employees e are optional in this scenario):
select *
from categories c,
orders o,
outer (employees e),
person p
where c.categoryid = o.categoryid
and p.personid = e.id
and o.employeeid = e.id
and o.orderid = 7742
and e.term_date is NULL
I'd need to think hard before coming up with data sets that could distinguish between the two queries (either the original query in the question and the slight rewrite above, or between Mike's answer and mine).
One other nagging doubt is that Informix's old-style non-standard OUTER join notation has a quirk that the standard notation simply does not support. The problem can occur when filtering on data in the subordinate table (RHS of a left outer join). The rows in the dominant table (in this case, tables — orders and categories) are preserved by Informix even when there was a match in the subordinate table that got filtered out. I think that it works OK this time because the filter condition that I'm concerned about, which is AND e.term_date IS NULL, uses IS NULL. You could run into the problem if the filter condition was AND e.term_date > MDY(7,4,2032) (and there was a row in employees that did not match the filter condition), but I think IS NULL is OK. The Informix behaviour is hard to explain, and hard to justify beyond "that is the way it works and it was documented to work thus in 1987±2 years, and backwards compatibility deals with the rest". It is only the Informix-only OUTER join notation that behaves weirdly. The ANSI-standard LEFT OUTER JOIN notation works according to the standard. But it does make conversion a challenge if this quirk affects your legacy code.
TL;DR Test the query results very carefully.
Something like:
select *
from categories c
Join orders o
on c.categoryid = o.categoryid
Left Join employees e
on o.employeeid = e.id
Join person p
on e.id = p.personid
where o.orderid = 7742
and e.term_data is null
Related
I’m trying to join three tables. Two of these, N1 and N2, share an ID (PK) but they differ in the number of rows, so I have written two coalesce statements to clean up the PK and a related field:
SELECT
(SELECT COALESCE(N1.ID_Year, N2.ID_Year)) AS ID_Year,
(SELECT COALESCE(N1.ReceiverUniqueID, N2.ReceiverUniqueID)) AS AllNetworkRUID,
[…]
FROM N1
FULL OUTER JOIN N2
ON N1.ID_Year_RU = N2.ID_Year_RU
What I need to do is now join the third table, N3, to the second COALESCE field, ie to ‘AllNetworkRUID’, something like:
JOIN N3
ON N3.ID = AllnetworkRUID .
I’ve not been able to work out how to make that happen, of if it’s even possible.
Any suggestions?
When joining multiple tables, involving all join types (inner, left,cross, full etc), is there any specific order in which joins are evaluated, like we have BODMAS in Mathematics or it always reads from left to right in the order we specified.
I don't have the exact SQL but here is a sample SQL:
Select * from
A,
B
LEFT JOIN
C
ON B.ID = C.ID,
D
FULL JOIN
E
ON
D.ID = E.ID;
Will it be like A cross joining with B and the result Left joining with C and so on..?
OR
A cross joining with the Left join of B and C..
I may be asking too much but I want to do a left outer join between two cores
and get data from A only where B does not have related data.
Following is exactly my equivalent SQL query (for simplicity I have removed other conditions),
1. SELECT A.* FROM A AS A
WHERE A.ID NOT IN (SELECT B.A_ID FROM B AS B WHERE B.STATUS_ID != 1)
I understand that solr join is actually subquery, I need data from only A.
It would be very easy if the not was not there in where condition for sub query.
For example,
2. SELECT A.* FROM A AS A
WHERE A.ID IN (SELECT B.A_ID FROM B AS B WHERE B.STATUS_ID != 1)
I can have q={!join from=aId to=id fromIndex=b}(-statusId:1).
How can I do a nagete here, i.e. solr query for 1
I'm joining multiple tables and I found two solution. I can't ready figure out what is the diference. Can anyone tell me?
Solution 1:
$query = $entityManager->createQuery("
SELECT m FROM Model m
JOIN m.battery b
JOIN m.camera c
JOIN m.connectivity co
JOIN m.hardware h
JOIN m.screen s
JOIN m.sensor se
WHERE b = m.battery
AND c = m.camera
AND co = m.connectivity
AND h = m.hardware
AND s = m.screen
AND se = m.sensor"
);
Solution 2:
$query = $entityManager->createQuery("
SELECT m FROM Model m
JOIN m.battery b
WITH m.battery = b
JOIN m.camera c
WITH m.camera = c
JOIN m.connectivity co
WITH m.connectivity = co
JOIN m.hardware h
WITH m.hardware = h
JOIN m.screen s
WITH m.screen = s
JOIN m.sensor se
WITH m.sensor = se
");
You are writing DQL and you should not confuse it with SQL. In a DQL query join you don't need to add id fields explicitly to the join Doctrine takes care of it for you.
"SELECT m FROM Model m JOIN m.battery b" is sufficient.
to fetch-join add b to your select clause:
"SELECT m, b FROM Model m JOIN m.battery b"
If you want to join only batteries with a certain property, that is when you need to use the WITH clause in your DQL. For example join only batteries who's battery status is empty:
"SELECT m, b FROM Model m JOIN m.battery b WITH b.status = 'empty'"
Check the documentation on DQL joins for more information.
From what i have read i can say:
When you use Where instead of On in join, there is one difference, On will apply before selection and Where will apply after the selection process by join. WITH is similar to On clause which lets you specify another condition in addition to On.
So I think when you use With, It will work like ON but Where will eliminate the result after selection by Join.
It may helps: Stack Overflow:
Selected Answer of this question also used two of them together with explanation.
I have 3 oracle tables. A joins to B and B joins to C. I want all records from A irerspective of whether a corresponding record exists in B or C. I wrote a query like this:
select a.name from a,b,c where a.a_id = b.b_id(+) and b.b_id = c.c_id(+)
This query does not seem right to me, particularly with the second join. What will exactly happen if there is a record in A but correspondingly nothing in B and C? Will it still fetch the record?
For some reason the above query returns same count of records as select a.name from a
So I am guessing that the query is right? Also is there a better way to rewrite the query?
I presume the better query can be
Select a.name from A a left join B b on a.a_id=b.b_id inner join C c on b.b_id=c.c_id
This should give the result as you have expected
http://rajanmaharjan.com.np