It doesn’t arbitrarily double rows or something. For each row in the relation on the left of the join, it will produce 1 or more rows depending on how many rows in the relation on the right of the join match the join condition. The output relation of the join may have duplicate rows depending on the contents of each joined relation as well as what columns you are projecting from each.
If you want to remove duplicates, that’s what DISTINCT is for.
To be honest, it’s remarkably simple for what it’s doing. There’s a ton of details that are abstracted away. Databases are massively complex things, yet we can write simple queries to interact with them, with semantics that are well-understood and documented. I think, like anything else, it requires a bit of effort to learn (not a lot, though). Once you do, it’s pretty easy to use. I’ve seen many non-technical people learn enough to write one-off queries for their own purposes, which I think is a testament to its simplicity.
Oneliners are simple I give that to you, but then you have those incomplete tables and whatnot. Like take all entries from A and join B on A.id and B.id, set the result to some default if B doesn’t exist.
You are surely going to whip up a perfect string of SQL but I’d struggle.
That’s the whole point of a left join? Anything else wouldn’t be a left join anymore.
Well I didn’t expect doubles. I’m sure not an expert.
It doesn’t arbitrarily double rows or something. For each row in the relation on the left of the join, it will produce 1 or more rows depending on how many rows in the relation on the right of the join match the join condition. The output relation of the join may have duplicate rows depending on the contents of each joined relation as well as what columns you are projecting from each.
If you want to remove duplicates, that’s what
DISTINCTis for.Thanks, I will kot forget that the next time I have to do SQL!
Still wild there are no simpler language that have grown in popilarity for databases though.
To be honest, it’s remarkably simple for what it’s doing. There’s a ton of details that are abstracted away. Databases are massively complex things, yet we can write simple queries to interact with them, with semantics that are well-understood and documented. I think, like anything else, it requires a bit of effort to learn (not a lot, though). Once you do, it’s pretty easy to use. I’ve seen many non-technical people learn enough to write one-off queries for their own purposes, which I think is a testament to its simplicity.
Oneliners are simple I give that to you, but then you have those incomplete tables and whatnot. Like take all entries from A and join B on A.id and B.id, set the result to some default if B doesn’t exist.
You are surely going to whip up a perfect string of SQL but I’d struggle.