3 ms·
Just that deeply inside that forest of functions you just wrote is the inner join that the SQL query would do in a couple of lines of code embedded.
by fifilura 3y ago
Just that deeply inside that forest of functions you just wrote is the inner join that the SQL query would do in a couple of lines of code embedded.
- calvinmorrison 3y agomore like, when it comes to complex data structures and logic, i will do that outside of sql. I'll do a join with sql no problem, by the time we're doing multiple inner joins I usually prefer to just do multiple sql queries. I don't care about performance that badly.
- fifilura 3y agoI usually only do one join at a time. But I separate them with CTEs ("WITH"). I can agree that many joins at once can make you grow grey hair.
- ako 3y agoThat’ll often not scale to millions of records. Letting the database optimizer find the optimal execution path instead of doing it procedurally elsewhere might result in “finishes in 5 minutes”, versus “doesn’t fit in a night”.
- threeseed 3y agoThis isn’t the 90s. Most hardware is way over-specced for the data sizes most people are dealing with. The number of use cases which are too heavy to finish in hours but small enough to fit in a single instance is pretty limited.
- fifilura 3y agoSQL is popular because it can be run on a map/reduce backend. So once you have written your code it can run on any number of machines.
- ako 3y agoCosts are another reason to optimize queries, long running, inefficient queries will be a lot more expensive on things like snowflake than more efficient queries.