Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SQL Select question
Message
From
21/12/2022 15:14:19
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
01685415
Message ID:
01685568
Views:
62
Hi, Dmitry, I realize this specific thread is a few weeks old, and I believe you got your answer, but just to emphasize something....(and I learned this from Sergey years ago)
select Table1.USER_NAME as USER_1, MAX(USER_EMAIL) as USER_1_EMAIL, MAX(DATE_IN) AS USER1_LASTDATE_IN FROM Table1
LEFT JOIN Table3 on Table1.USER_NAME = Table3.USER_NAME GROUP BY Table1.USER_NAME 
LEFT JOIN Table2 ON Table2.USER_PK = Table1.USER_PK
In most (maybe even all?) implementations of SQL, any time you issue a SQL SELECT against a pattern of multiple 1-many relationships from the same parent table, you MUST use a subquery of some type. Best of my knowledge, any time you issue a straight SELECT against multiple 1-many relationships , you'll wind up getting incorrect/over-aggregated results. When I taught SQL I used the following scenario...seemingly a very simple one....to show when subqueries are required.

If you join Table A (a master table of jobs) to Table B (a table of employee hours per job).....and let's say that Job XYZ has 4 timesheet rows in Table B.
And then you join Table A to Table C ( a list of purchase records per job), and let's say that Job XYZ has 3 purchase rows in Table C ...

If you join Table A to Table B and then Table A to Table C in the same SELECT, here's what will happen....when you try to do it all at once.

The "internal product" of the join between A and B will produce 4 instances of Job XYZ....(for each of the four timesheet rows)
The "internal product" of the join between A and C will produce 3 instances of Job XYZ.....for each of the 3 timesheet rows

When A is Joined to C.....the four instances of the product from A to B will be used...and so the sum of your purchase amount will be 4X higher.
When A is joined to B.....the three instances of the produce from A to C will be used....and the sum of your timesheet rows will be 3X higher.

So, you're not "just" joining A to C....you're joining on "whatever got joined to A from other JOINs" to C
And you're not "just" joining A to B....you're joining on "whatever got joined to A from other JOINs" to B.

It's not a bug, it's one of those situations where SQL is doing exactly what we are telling it to do, not what we "want" it to do.

So again, any time you have a master table being joined to multiple 1-many tables, you must use a subquery to break it down, to avoid this pattern.

Hope that helps....
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform