For joins in SQL, Is common column not compulsory? - sql

Question

I came to know that we can use other than JOIN ON a.col = b.col, with JOIN ON a.col CONDITION b.col2. How does it works?.
Example:
2 Tables are:
We can join them as follows (ignoring the required output code, how is that join worked?)
SELECT Students.Name, Grades.Grade, Students.Marks FROM Students
INNER JOIN Grades ON Students.Marks BETWEEN Grades.Min_Mark AND Max_Mark
WHERE Grades.Grade > 7
ORDER BY Grades.Grade DESC, Students.Name ASC;

Answer 1

Joins don't have to nominate a column at all:
SELECT * FROM People CROSS JOIN Addresses
This combines all people with all addresses. If there were 2 people and 3 addresses, 6 records would result
Person.Name, Address.Name
-------------------------
Person1, Address1
Person1, Address2
Person1, Address3
Person2, Address1
Person2, Address2
Person2, Address3
Joins that have a condition don't have to use any columns from the sets of data being joined, they just have to evaluate to true in order for the row to appear in the output. You can consider that when a database is processing any join, it first produces the cross product of every row (like above) then the truth of the condition is checked per row to decide which of those rows make it into the output
First let's do a join on something that makes some sense, using the above data
SELECT * FROM People INNER JOIN Addresses ON Person.Name = Address.Name
That would produce nothing, because 'Person1' is never equal to 'Address1' and so on.. But suppose we altered it to:
SELECT * FROM People INNER JOIN Addresses ON REPLACE(Person.Name, 'Person', 'Address') = Address.Name
The 6 rows would be prepared like before:
Person1, Address1
Person1, Address2
Person1, Address3
Person2, Address1
Person2, Address2
Person2, Address3
The DB would replace the word Person with the word Address just while it was evaluating the truth of the join, and the tests would be performed:
Person1, Address1 --'Person1'->'Address1', does 'Address1'='Address1'? YES; OUTPUT the row
Person1, Address2 --'Person1'->'Address1', does 'Address1'='Address2'? no; discard the row
Person1, Address3 --'Person1'->'Address1', does 'Address1'='Address3'? no; discard the row
Person1, Address1 --'Person2'->'Address2', does 'Address2'='Address1'? no; discard the row
Person2, Address2 --'Person2'->'Address2', does 'Address2'='Address2'? YES; OUTPUT the row
Person2, Address3 --'Person2'->'Address2', does 'Address2'='Address3'? no; discard the row
So you get 2 rows:
Person1, Address1
Person2, Address2
Now let's make it really wacky; Suppose you had:
SELECT * FROM People INNER JOIN Addresses ON DAY_OF_WEEK(NOW()) = 'Monday'
The query would produce 6 rows, but only on Monday. As soon as it turned to Tuesday the query would produce 0 rows. It doesn't make much sense to do, but you're still allowed to do it. So long as you provide something the DB can evaluate to true, or false, the DB will join every row to every other row, then check the truth for every combination, and discard any combination if it sees a false
Imagine other scenarios. Person and Address are supposed to be related on Address having a PersonId
If you did:
SELECT * FROM People LEFT JOIN Addresses ON Person.Id = (Address.PersonId + 1)
You'd see:
PersonId, Name, Address_PersonId, Street
0, Tim, NULL, NULL
1, John, 0, TheRoad
2, Mary, 1, TheAvenue
It's supposed to be Tim that lives at TheRoad, but we wrote a nonsensical join condition that was evaluated and churned out results anyway
You could divide the ID by 2, you could join on a random number being less than 0.5.. It doesn't matter, it's just a truth and most of the time it's at its most useful when it uses column data..
how is that join worked?
This BETWEEN form is actually quite a useful one. It allows you to band loads of different scores into set bands.
Suppose you have 2 people scores and 3 bands (i'm keeping it small to make it easier to type out):
Name, Score
Tim, 79
John, 68
ScoreLower, ScoreHigher, Rating
0, 50, Bronze
51, 75, Silver
76, 100, Gold
And you do
SELECT * FROM People JOIN Scores ON Score BETWEEN ScoreLower AND ScoreHigher
Remember that the DB conceptually combines EVERY person with EVERY score band first:
Tim, 79, 0, 50, Bronze
Tim, 79, 51, 75, Silver
Tim, 79, 76, 100, Gold
John, 68, 0, 50, Bronze
John, 68, 51, 75, Silver
John, 68, 76, 100, Gold
And then it goes through knocking out the ones that aren't true
Tim, 79, 0, 50, Bronze --FALSE, 79 is not BETWEEN 0 and 50, discard this one
Tim, 79, 51, 75, Silver --FALSE, 79 is not BETWEEN 51 and 75, discard this one
Tim, 79, 76, 100, Gold --TRUE, keep
John, 68, 0, 50, Bronze --FALSE, discard
John, 68, 51, 75, Silver --TRUE, keep
John, 68, 76, 100, Gold --FALSE, discard
And you get just the keeps:
Tim, 79, 76, 100, Gold
John, 68, 51, 75, Silver
You could have a list of all the chinese astrological years, and a list of people with a known birthday, and then do their birthday BETWEEN yearstart AND yearend and find out if they're a Horse, Dog etc.. You could have a list of all the letters in the alphabet and a color, and put people into color groups based on the first letter of their name. It doesn't have to be =, we could use LIKE:
People JOIN AlphabetColors ON People.FirstName LIKE AlphabetColors.Letter + '%'
Or we could:
People JOIN AlphabetColors ON LEFT(People.FirstName, 1) = AlphabetColors.Letter
Either way, data like:
Albert
Bill
Charlie
A, Red
B, Green
C, Blue
Ends up as
Albert, A, Red
Bill, B, Green
Charlie, C, Blue