5 ms·
I couldn’t agree more with your last comment. A lot of folks strive for optimizations in their application language of choice...relying on standard SQL queries
by pupdogg 7y ago
I couldn’t agree more with your last comment. A lot of folks strive for optimizations in their application language of choice...relying on standard SQL queries (aka joins and unions that fit most use cases but not specific ones). ORMs have also come a long way...but...if you know your SQL, you can be lethal!
- trevyn 7y agoCould you give an example of a “lethal” query?
- war1025 7y agoDon't know that its necessarily "lethal", but one thing I've learned over the years is to let the database do the calculations for you. For example, we've had numerous places over the years where we would pull hundreds or thousands of records out of the database, and then process them on the server to get just a handful of result values. Moving the calculations down to SQL saves a ton of bandwidth and also lets the query optimizer make good choices for you. Learning how to analyze queries and write the proper indexes to make things run fast is also a good skill. In Postgres, learning how to use the builtin json functions is very helpful too. Also learning about aggregate functions and things like that. Really I've found that most of my learning happens when I come across something that people are saying is too slow, and then I read up and think about the problem and usually learn a new trick or two to make everything work a little bit happier. Also even just the very basic things like properly setting up foreign keys, constraints, etc. can get you a long way. For a long time my coworkers were reluctant to do anything that operated on more than one table at a time. And if they did it was all using ORM magic, which is useful in a way, but also pretty handicapped as far as efficiency.