3 ms·
Sometimes it's better to do things in the application instead of caking it in an sql query. An example would be a subquery that yields a large temp table, only
by matthewaveryusa 3y ago
Sometimes it's better to do things in the application instead of caking it in an sql query.
An example would be a subquery that yields a large temp table, only to be pruned down to a single row.
Your choice is to either have understanding of the query optimizer and formulate a query that forces the subquery with a smaller temp table first, or you can bring it back to the application. Either approach works, but in once case you need to have deep-ish understanding of the optimizer and SQL, and in the other not so much (at the cost of an RTT.)
- sgarland 3y ago> but in once case you need to have deep-ish understanding of the optimizer and SQL I will never understand why devs think they need to understand their chosen application well, but not SQL. Your application relies on SQL, so why shouldn't you deeply understand it? Relational algebra isn't that complex compared to other things we take for granted as necessary.
- whynotmaybe 3y agoBringing more data to the app so that the app filters it instead of the DB server is always wrong. An app with such solution is a sign of mutliple issues that either the DB schema is wrong, or that the devs don't know enough Sql, or both. Sql has been there for decades, much less longer than many of the actual dev framework. PostgreSQL (and other DBMS) have also been there for decades, they have perfected the art of fetching data.
- jon-wood 3y agoNothing is ever "always wrong". It may be a sign that a little more thought can lead to a more maintainable/quick/efficient solution, but it may also be that under the circumstances an approach that would be the wrong one if applied widely actually is the correct tradeoff between those factors in this case.