4 ms·
Nearly 30 years of SQL experience here, I tell new people there's really no advanced SQL, just "exotic" SQL. (Or a joke: "There's 3 types of Advanced SQL. Reall
by kthejoker2 5y ago
Nearly 30 years of SQL experience here, I tell new people there's really no advanced SQL, just "exotic" SQL. (Or a joke: "There's 3 types of Advanced SQL. Really long SQL. Exotic SQL. And SQL no one should have written.")
The "advanced" part is:
1) Set Theory - really understanding set theory so you can model datasets appropriately and write efficient SQL
2) The Toolkit - knowing how the major concepts of SQL (join types, CTEs, table valued functions, windowing, aggregation, conditional logic, indexes, constraints, normalization/denormalization, etc.) contribute to #1
3) Performance Analysis - understanding how to analyze the performance characteristics of a query so you can apply #2 to #1 to achieve good results
And usually the difference I see between juniors and seniors is if you give them 2 "advanced" queries and tell them one runs fine and one doesn't, seniors very quickly know which one is bad and why it runs bad ... juniors aren't even confident the two queries will run because they contain syntax or patterns they're unfamiliar with.
- denton-scratch 5y ago> really long SQL Some systems generate really long SQL queries; I'm thinking of you, Drupal! I haven't worked with D8, and only a little with D7. But D6 would routinely produce SELECT queries with 20 tables joined. Drupal is notorious for caching nearly everything, including the results of SQL queries, because those queries were essentially untunable (and the "cache" was usually yet another database table). "Flush all of the caches" was the first advice to anyone struggling with a D6 issue.