Does anyone have a really good example where there are two tables with a OneToMany relationship where doing a left join with Table B as the target would be less useful than just doing a left join with table A as the target using the WHERE clause.
Table A (ManyToOne with Table B)
Pk
Number
Fk
Table B
Pk
IsActive
I mean, I can write a join like so
select * from TableA as a left outer join TableB as b on b.pk=a.fk where b.isActive=false and a.Number < 15
instead of writing
select * from TableB as b left outer join TableA as a on b.pk=a.fk where b.isActive=false and a.Number < 15
I mean, if I was supporting joins on a noSQL system, when would I ever need to support the second one because someone could not just rewrite it as the first one above AND is there a good use case for this so I can wrap my head around when it would be used?
The reason I ask is in object query language, I am wondering if I ever need to support doing a where clause in this situation(or instead if I just disallow something like this)…
select b from TableB as b left fetch join b.tableAList as a where b.isActive=true and a.xxxxx = something
but isn’t that invalid since b has many a rows so a.xxxx is invalid as it is a list and could only really be a.size which would be count of the rows in the list of a rows for that b row.
thanks,
Dean
Both of your examples are effectively inner joins.
When you do a left outer join, the values in the second table are NULL. Your WHERE clause is:
NULL values will cause this to fail, removing all the “virtual” rows added from the second table.
If you really want a left outer join, then you need to include these in the ON clause rather than the WHERE clause.
In general, though,
A LEFT OUTER JOIN BandB LEFT OUTER JOIN Aare quite different. The first keeps all rows in A, with the matching rows from B (or NULL values if there is no match). The second keeps all rows in B, with all the matching rows from A (or NULL values if there is no match).