Don't understand why inner join is necessary for filtering in sql - sql

Question

I have the following tables:
Basically I have a many2many relation between students and courses using the junction table students_courses
Here is some data populated into the tables:
students:
courses
students_courses:
So basically I would like to select the full_name and c_id for a given student. So for example for student with id=3 i would have Aurica 5 and Aurica 6.
My first approach was to write:
select s.full_name,sc.c_id from students s, students_courses sc
where sc.s_id=3
But i obtain this:
Aurica 5
Aurica 6
Aurica 5
Aurica 6
Aurica 5
Aurica 6
So it is duplicated by the number of rows of the students_courses table. Now I'm not sure why this happens.
If I would be an SQL parser, I would parse it like this:
"take the c_id from students_courses, full_name from students, and display them if the students_course row respects the where filter"
Not it works using join, but I don't really understand why the inner join is necessary.
select s.full_name, sc.c_id from students s
inner join students_courses sc
on sc.s_id=s.id and s.id=3;
Explain a bit how is the first sql interpreted by the SQL parser and why with join works.
Thanks,

Answer 1

When you select information from two tables what it does is a cross product of all the records and then it looks to the all of the records that satisfy the where clause. You have 3 records in the Students table
id | full_name
---+----------
3 | Aurica
4 | Aurica
5 | Aurica
And 6 records in the student_courses table.
s_is | c_id
-----+-----
3 | 5
3 | 6
4 | 7
4 | 8
5 | 9
5 | 10
So before your where statement it creates 18 different records. So it is easy to see I will include all of the columns.
s.id | s.full_name | sc.s_id | sc.c_id
-----+-------------+---------+--------
3 | Aurica | 3 | 5
3 | Aurica | 3 | 6
3 | Aurica | 4 | 7
3 | Aurica | 4 | 8
3 | Aurica | 5 | 9
3 | Aurica | 5 | 10
4 | Aurica | 3 | 5
4 | Aurica | 3 | 6
4 | Aurica | 4 | 7
4 | Aurica | 4 | 8
4 | Aurica | 5 | 9
4 | Aurica | 5 | 10
5 | Aurica | 3 | 5
5 | Aurica | 3 | 6
5 | Aurica | 4 | 7
5 | Aurica | 4 | 8
5 | Aurica | 5 | 9
5 | Aurica | 5 | 10
From there it only displays the ones where cs.id=3
s.full_name | sc.c_id
------------+--------
Aurica | 5
Aurica | 6
Aurica | 5
Aurica | 6
Aurica | 5
Aurica | 6
The second query you had compared the value of sc.s_id=s.id and only displays the ones where those values are the same, as well as the c_id=3

Answer 2

The SQL parser doesn't try to guess how your two tables are related. It would seem like the database engine has enough information to figure this out itself by following constraints, but SQL intentionally doesn't use the FK relationships to decide how to join your tables; you might want to remove constraints at at future date for some reason (such as in order to improve performance), and you wouldn't want dropping a constraint to alter how joins were made. The DBA needs freedom to change indexes and constraints without having to worry about having changed what results are returned by queries.
Since it can't count on having complete information to go on, the SQL engine is not in the business of deducing/guessing relationships. It's up to the person writing the SQL to specify what they are joining on. If you don't give it any instructions telling it how to hook up the tables (using a JOIN ON clause or WHERE clause) then it creates a cross join, which gives you the duplicated results.

Answer 3

First of all, SQL is a set-based language, you operate on sets of data, not on single (rows of) data.
If I would be an SQL parser, I would parse it like this: "take the
c_id from students_courses, full_name from students, and display them
if the students_course row respects the where filter"
Here, you're overlooking the sets students_courses and students, and just thinking about each row of data, like if this rows respects the filter, give me all the informations.
The JOIN doesn't filter data (that's what WHERE does), but instead it puts it together.
When you SELECT from table A, you ask for the set of rows in A, all of them.
When you SELECT from table A WHERE some condition, you ask for the set of rows in A that respect the condition (so the SQL engine discards rows from A that do not belong to the set you described with your query).
When you JOIN table_a and table_b, you ask to join the set of rows in a with the set of rows in b, obtaining a new set whose rows are the "concatenation" (let me use that term) of the columns from a row in A and the columns from a row in B; this, without giving any other information about how to join the rows, simply results in each row of table_a joined with each row of table_b.
That's why you don't get what you expect.
Finally, from a conceptual point of view, I'd like to point out that the SQL engine doesn't take the columns you request from a table or another, but after (1) having joined the rows in any table you requested and (2) having filtered out any row that doesn't match the where condition, it just return the columns you requested from the rows of the resulting set after (1) and (2).
In real life, RDBMS may reorder these operations, and apply any kind of optimization they find possible based on indexes and other query and tables informations they have available.
This should give you a rough idea of what's going on. But as #GordonLinoff suggested you, I think you should get a stronger basis about SQL and relational databases before you go any further, or it will get harder than this.
As a side note, what you had in your FROM clause, is a sort of implicit join, a former join syntax in which the FROM clause specifies the tables involved, and the WHERE clause the join predicate (the columns whose values should match to join the data).

Answer 4

If you would have done something like
select s.full_name,sc.c_id
from students s, students_courses sc
where sc.s_id = s.id --<-- you left this out
AND sc.s_id=3
You would have got the same results, Inner join is not necessary for this statement but it is a good practice to use this newer INNER JOIN Syntax to retrieve data.

Answer 5

Both of your queries are in fact joins, only in your first example there is no word "join" (but it is there, trust me).
However, that's an old style join and it's not recommended to use any more. In short, it's about NULL values - this old style join has an problem with interpreting NULL values and that's why you have wrong result.
For more details see here.