4 ms·
SQL gets a bad reputation from programmers that have a strictly procedural understanding of problem solving. When you are dealing with large amounts of data a
by treebeard901 10y ago
SQL gets a bad reputation from programmers that have a strictly procedural understanding of problem solving.
When you are dealing with large amounts of data a SET based approach to data retrieval will likely be the better solution. The problem often comes from trying to bridge the procedural world with the set based world.
- akavi 10y agoSQL 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 10y 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.