3 ms·
SQL also gets a bad reputation from programmers that have a SET based approach to data too, because it's horribly uncomposable. When I try and solve a problem
by akavi 11y ago
SQL also gets a bad reputation from programmers that have a SET based approach to data too, because it's horribly uncomposable.
When I try and solve a problem with SQL, it's generally trivial to produce a solution in relational algebra pseudocode , and convert that in turn into a deeeeeeeply nested, horribly nonperformant almost SQL query. Then I have to go through to try and unnest it, fix all the little "gotchas" involving "GROUP BY" and "HAVING" and implicit aliasing, and somehow make it performant (Admittedly, that last one is usually the DB optimizer's fault.)
Relational algebra is a beautiful way to answer many questions. The issue is SQL isn't a very good way of writing it.
- dsp1234 11y agoand convert that in turn into a deeeeeeeply nested I find that CTEs are the solution to deep nesting. There are very few times that I haven't been able to reduce the amount of nesting down to 2 levels (just the a single query with a subquery as part of an exists or something). That's obviously a problem if you don't have access to CTEs (mysql) or CTEs are an optimization boundary (postgres), but if you're working with a product that does not have those issues, then CTEs can really clean up a lot of sql.