5 ms·
I don't thinks so. You don't have to use join, but you might end up with loads of queries instead of having just one, but the end result will be the same set of
by MrLeftHand 10y ago
I don't thinks so. You don't have to use join, but you might end up with loads of queries instead of having just one, but the end result will be the same set of data.
- arethuza 10y agoIf the data you are querying is spread across multiple tables (and in "enterprise" environments databases with hundreds, thousands, tens of thousands of tables or more are fairly common) then you have to do a join somewhere - in SQL, in your application or even manually. Given that doing the join in SQL is by far the most common scenario not being aware of it is a bit odd!
- pjmorris 10y agoArguably that's one year of SQL experience repeated five times.
- dllthomas 10y agoOr one week of SQL experience repeated 250 times...
- pedrosorio 10y agoOne day?
- dllthomas 10y agoArguably.
- sotojuan 10y agoYep. Believe it or not depending on the team/manager/programmer that happens very often.
- joshyeager 10y agoBut if you have loads of queries and do the "join" in your application code, you will suffer serious performance problems with any reasonable data set. If a programmer is going to be writing SQL for anything larger than a toy problem, they have to know how to use JOIN.
- krzyk 10y agoOr you can use where a.id = b.id and you cover 90% of joins (inner join). I only once needed an outer join in the last 10 years all other cases and here inner joins. And I prefer the where syntax, it's cleaner for me than the join one.