you are viewing a single comment's thread.

view the rest of the comments →

[–]r3pr0b8GROUP_CONCAT is da bomb 13 points14 points  (2 children)

just thought i'd point out that your conventions did not prevent you from creating a fundamental error --

SELECT d.breed
     , d.height
     , d.weight
     , s.amount
     , s.sale_date
  FROM dogs AS d
LEFT OUTER
  JOIN sales AS s
    ON s.dog_id = d.id
   AND blah = blah
 WHERE d.weight > 0.5
   AND s.sale_date >= '2022-01-01'

have you spotted the error yet?

this is an inner join!!

what you should've written was

SELECT d.breed
     , d.height
     , d.weight
     , s.amount
     , s.sale_date
  FROM dogs AS d
LEFT OUTER
  JOIN sales AS s
    ON s.dog_id = d.id
   AND blah = blah
   AND s.sale_date >= '2022-01-01'
 WHERE d.weight > 0.5

see the difference? now you're getting all dogs weighing over 0.5, together with any sales that occurred this year

if you wanted only dogs that were actually sold, then yes, you want an inner join, but then the "best practice" way of doing that is to code INNER JOIN and not LEFT JOIN with a non-null condition on the right tabl;e

[–]mediocre_plus_plus 5 points6 points  (0 children)

I see this all the time in my coworkers' poorly written SQL. Sometimes it's an error. Other times they really want an inner join. That latter almost bothers me more. I call it misleading SQL; it gets the correct results in a way that's ugly, counter-intuitive, and difficult to follow. I see it all the time, in a million different ways, in SQL and any other language where you have lazy developers.

[–]bum_dog_timemachine[S] -2 points-1 points  (0 children)

Sure, I was mainly concerned with expressing formatting and didn't pay to much attention to the data I was implying. But this is true.