Yes! Typical software engineers (who usually hate working with relational databases) write the same exact patterns of SQL.
The most common one is joins vs subqueries.
An analyst will write:
SELECT t1.col1
FROM table1 t1
JOIN table2 t2 ON t1.key = t2.key
WHERE
Yes! Typical software engineers (who usually hate working with relational databases) write the same exact patterns of SQL.
The most common one is joins vs subqueries.
An analyst will write:
SELECT t1.col1
FROM table1 t1
JOIN table2 t2 ON t1.key = t2.key
WHERE
@ergestx Haha whattttt. Isnt the second one way slower?
@ergestx Our DB course instructor at college would write SELECT t1.col1 FROM table1 t1, table2 t2 WHERE t1.key = t2.key AND <condition> "query planner would handle it..."
@ergestx i typically use WHERE EXISTS as i was told it’s faster than both, but wondering now if the query planner executes them the same way?
@ergestx Analysts write the first one because they might want to look at columns from table 2. SWEs write the second one because it says exactly what they’re doing. And the query planner doesn’t care. The comments are distressing me.
@ergestx I’m absolutely a JOIN guy because it’s basically the SQL equivalent of Excel’s vlookup / xlookup, so it’s a default way of thinking for me
@ergestx As soon as you start dealing with tables containing millions of rows, you may find that sub query is way more efficient way to filter needed data. Especially if you have more than just two tables to access those ids. Join is a typical way to lock all tables in question for long