Can anyone explain what the (+) sign means in the below code.
SELECT DISTINCT ph.po_nbr, rd.id
FROM po_head a, rtable_dtl e
WHERE a.org = e.org (+)
AND a.menu_nbr = e.menu_nbr(+)
AND UPPER(a.user_id) = UPPER(e.user_id(+))
An example:
SELECT
t0.foo, t1.bar
FROM
FIRST_TABLE t0, SECOND_TABLE t1
WHERE
t0.ID (+) = t1.ID;
This is an Oracle-specific notation for an outer join. It means that it will include all rows from t1, and use NULLS in the t0 columns if there is no corresponding row in t0.
In standard SQL one would write:
SELECT t0.foo, t1.bar
FROM FIRST_TABLE t0
RIGHT OUTER JOIN SECOND_TABLE t1;
Oracle recommends not to use those joins anymore if your version supports ANSI joins (LEFT/RIGHT JOIN):
Oracle recommends that you use the FROM clause OUTER JOIN syntax rather than the Oracle join operator. Outer join queries that use the Oracle join operator (+) are subject to the following rules and restrictions […]
Related
I am using an old database call Centura Gupta that doesn't have the join clauses (left join, right join, inner join, outer join). So I need to use where to replace the outer join that I need:
SELECT *
FROM table1
OUTER JOIN table2
ON table1.id_person table2.id_person;
I think that where can only replaces inner join:
SELECT *
FROM table1
WHERE table1.id_person = table2.id_person;
You could try to use subqueries instead of join
SELECT *
FROM table1 t1
WHERE id_Person IN
(
SELECT id_Person
FROM table2
)
I used this kind of implementation when I didn't know JOINs. May not be exactly right but something which can get you close:
SELECT *
FROM table1 t1, table2 t2
WHERE t1.id_Person=t2.id_Person;
I don't know about that particular database, but you might be able to use a correlated subquery to get "joined" data. This will pull all records from table1 and the related info from table2, or NULL for whatever4 and whatever5 if there's no matching id_person in table2:
SELECT t1.whatever1
, t1.whatever2
, t1.whatever3
, (SELECT whatever4 FROM table2 AS t2 WHERE t2.id_person = t1.id_person) AS whatever4
, (SELECT whatever5 FROM table2 AS t2 WHERE t2.id_person = t1.id_person) AS whatever5
FROM table1 AS t1
'Old database called Centura Gupta' ??
Maybe you actually mean OpenText Gupta SQLBase - which is by no means 'old'.
You may be running an 'old' version of SQLBase - but it is now up to v12.2 native 64bit, and outer joins are certainly supported.
You can either use the native Gupta outer joins - similar to Oracle (+) or standard ANSI outer joins.
If you want to use ANSI OUTER joins, specify 'ANSIJoinSyntax=1' in your Server side Sql.ini
Go here for more SQLBase Join syntax: Gupta SQLBase Manuals
Native Gupta Outer Join:
SELECT t1.id_person, t2.id_person
From table1 t1 , table t2
Where t1.id_person = t2.id_person(+)
ANSI Outer Join:
SELECT t1.person_id, t2.person_id
From table1 t1
Left Outer Join table2 t2 ON t1.id_person = t2.id_person
Where <what ever filter you want>
Go here for more SQLBase Join syntax: Gupta SQLBase Manuals
This question already has answers here:
Select from Table1, Table2
(3 answers)
Closed 4 years ago.
I know different joins, but I wanted to know which of them is being used when we run queries like this:
select * from table1 t1, table2 t2
is it full outer join or natural join for example?
Also does it have a unique meaning among different databases or all do the same?
UPDATE: what if we add where clause ? will it be always inner join?
The comma in the from clause -- by itself -- is equivalent to cross join in almost all databases. So:
from table1 t1, table2 t2
is functionally equivalent to:
from table1 t1 cross join table2 t2
They are not exactly equivalent, because the scoping rules within the from clause are slightly different. So:
from table1 t1, table2 t2 join
table3 t3
on t1.x = t3.x
generates an error, whereas the equivalent query with cross join works.
In general, conditions in the WHERE clause will always result in the INNER JOIN. However, some databases have extended the syntax to support outer joins in the WHERE clause.
I can think of one exception where the comma does not mean CROSS JOIN. Google's BigQuery originally used the comma for UNION ALL. However, that is only in Legacy SQL and they have removed that in Standard SQL.
Commas in the FROM clause have been out of fashion since the 1900s. They are the "original" form of joining tables in SQL, but explicit JOIN syntax is much better.
To me, they also mean someone who learned SQL decades ago and refused to learn about outer joins, or someone who has learned SQL from ancient materials -- and doesn't know a lot of other things that SQL does.
demo: db<>fiddle
This is a CROSS JOIN (cartesian product). So both of the following queries are equal
SELECT * FROM table1, table2 -- implicit CROSS JOIN
SELECT * FROM table1 CROSS JOIN table1 -- explicit CROSS JOIN
concerning UPDATE
A WHERE clause makes the general CROSS JOIN to an INNER JOIN. An INNER JOIN can be got by three ways:
SELECT * FROM table1, table2 WHERE table1.id = table2.id -- implicit CROSS JOIN notation
SELECT * FROM table1 CROSS JOIN table2 WHERE table1.id = table2.id -- really unusual!: explicit CROSS JOIN notation
SELECT * FROM table1 INNER JOIN table2 ON (table1.id = table2.id) -- explicit INNER JOIN NOTATION
Further reading (wikipedia)
I need to merge below Table 1 & Table 2 as indicated in "Merge".
The query I wrote below works; but it is TOO SLOW! Is there any simpler way which returns it faster?
SELECT T1.Loc, T2.SO, T2.PO, T1.Item
FROM Table1 T1
LEFT OUTER JOIN Table2 T2
ON ISNULL(T1.[SO2],T1.[SO1]) = T2.[SO]
Never use commas in the FROM clause. Always use proper, explicit JOIN syntax:
SELECT *
FROM Table1 T1 LEFT OUTER JOIN
Table2 T2
ON COALESCE(T1.[SO2], T1.[SO1]) = T2.[SO];
There is no need to join to Table2 twice (much less getting a Cartesian product). I prefer COALESCE() to ISNULL() simply because the former is the ANSI standard function for replacing NULL values.
I should add that for performance, two joins might be preferable:
SELECT T1.Loc, COALESCE(T2_2.SO, T2_1.SO) as SO,
COALESCE(T2_2.PO, T2_1.PO) as PO, T1.Item
FROM Table1 T1 LEFT OUTER JOIN
Table2 T2_2
ON T1.[SO2] = T2_2.[SO] LEFT OUTER JOIN
Table2 T2_1
ON T1.[SO1] = T2_1.[SO] AND T1.[SO2] IS NULL;
It is easier for the SQL engine to optimize joins that use only equality and AND conditions, on the clean column references (that is, the columns are not the arguments to any function calls).
Hope this SQL full fill your requirement.
Select T2.Loc, T2.SO, T2.PO, T1.item from table 2 T2 join table1 T1
on T1.SO1 = T2.SO;
I know there is a WHERE representation of LEFT JOIN in Oracle that has syntax like:
FROM t1, t2
WHERE t1.id = t2.id(+)
instead of:
FROM t1 LEFT JOIN t2
ON t1.id = t2.id
Is there anything similar in PostgreSQL? I searched for documentation, but failed to find such feature.
There is no such operator in Postgres (or standard SQL).
The only way to write an outer join in Postgres is to use an ANSI explicit JOIN syntax:
select *
from table t1
left join table t2 on t1.id = t2.id;
(or it might be the other way round - it has been ages since I last used the Oracle (+) operator)
More details in the manual: http://www.postgresql.org/docs/current/static/queries-table-expressions.html#QUERIES-FROM
You shouldn't be using the (+) operator in Oracle in the first place. Oracle has supported ANSI joins since 9i and Oracle recommends stop using the (+) operator (the above statement will work just fine in Oracle as well)
The following query is automatically translated from the "old" syntax to ANSI syntax and gives an error:
select *
from ods_trf_pnb_stuf_lijst_adrsrt2 lst
join ods_stg_pnb_stuf_pers_adr pas
on (pas.soort_adres = lst.soort_adres)
right outer join ods_stg_pnb_stuf_pers_nat nat
on (prs.id = nat.prs_id) <<<prs.id invalid identifier
join ods_stg_pnb_stuf_adr adr
on (adr.id = pas.adr_id)
join ods_stg_pnb_stuf_np prs
on (prs.id = pas.prs_id)
I guess this is because table prs is referenced before it has been declared. Moving the prs join up in the query solves the problem:
select *
from ods_trf_pnb_stuf_lijst_adrsrt2 lst
join ods_stg_pnb_stuf_pers_adr pas
on (pas.soort_adres = lst.soort_adres)
join ods_stg_pnb_stuf_np prs <<< this first
on (prs.id = pas.prs_id)
right outer join ods_stg_pnb_stuf_pers_nat nat
on (prs.id = nat.prs_id) <<< now prs.id is known
join ods_stg_pnb_stuf_adr adr
on (adr.id = pas.adr_id)
where lst.persoonssoort = 'PERSOON'
and pas.einddatumrelatie is null
Is there a way to write this query so that the order is less restrictive, still using the ANSI syntax?
If the broken query was generated by a tool from the old non-ANSI syntax, the tools is generated broken code. However, using ANSI-style joins should yield the same result regardless of the order of tables in the from clause. That is
select *
from t1
join t2 on t2.id = t1.id
left join t3 on t3.id = t1.id
will give you the same results (albeit a different ordering of columns in the result set) as
select *
from t1
left join t3 on t3.id = t1.id
join t2 on t2.id = t1.id
Note that the from clause can't be reordered in such a way as to break the dependencies implied by the join criteria. However, you may also, restate/refactor the from clause so as to express the query in a different way that will yield the same result set. For instance, the above query is equivalent to
select *
from t3
right join t1 on t1.id = t3.id
join t2 on t2.id = t1.id
You simply cannot reference a table unless it has been in the join list earlier. That is normal and expected behavior. Why is this a problem?
A normal ("INNER") JOIN
SELECT ...
FROM a
JOIN b ON (a.x = b.y)
is equivalent to a SELECT with two tables and an appropiate WHERE clause
SELECT ...
FROM a, b
WHERE a.x = b.y
For left/right/outer joins, you are still handicapped by "the asymmetric" join syntax.
I think the original SQL code should be something looks like this,
select *
from ods_trf_pnb_stuf_lijst_adrsrt2 lst
, ods_stg_pnb_stuf_pers_adr pas
, ods_stg_pnb_stuf_pers_nat nat
, ods_stg_pnb_stuf_adr adr
, ods_stg_pnb_stuf_np prs
where
pas.soort_adres = lst.soort_adres
and prs.id(+) = nat.prs_id
and adr.id = pas.adr_id
and prs.id = pas.prs_id
and lst.persoonssoort = 'PERSOON'
and pas.einddatumrelatie is null
ods_stg_pnb_stuf_np prs is at the end of from clause which is valid in Oracle proprietary joins,
But when convert this to ANSI SQL syntax, table prs should be joined first before it was referenced. This is a common mistake that people made when convert Oracle proprietary joins to ANSI SQL syntax.
There are some other issues when convert Oracle proprietary joins to ANSI SQL syntax:
additional join condition was missing.
condition in where clause was broken after moving some conditions to join clause.
If your colleague need to rewrite Oracle proprietary joins to ANSI SQL syntax, demos(both in java and C#) listed in this article should be helpful.