How Modern SQL Databases Come up with Algorithms that You Would Have Never Dreamed Of by Lukas Eder

I use to think that too. This is a good talk about how smart SQL query engines are. It is an hour though [VIDEO]

I would suggest that learning SQL (the syntax) isn't the crux--it's just syntax you learn over time based off need, just like learning python--what you need is motivation. I'd suggest watching this video to get a flavor of how much leverage using the database can give you: [VIDEO] If the database can make you more productive and more efficient and make your life easier, you now have incentive to use it more. Another thing that took my use of databases to the next level, was using PostGraphile ( [LINK] ). It takes a PostgreSQL database and provides a GraphQL endpoint for it. Use that as your only backend. You can use PostgreSQL row-level security to do access control (who can see or modify what). You can use PL/pgSQL to write business logic for higher level calculations. You can use constraints and triggers to do data validation. Each of these areas has an initially steep learning curve, and wonky syntax, but once you get over them you can implement many backends extremely quickly with them. And using PostGraphile where you only have SQL available (well, you can also add javascript extensions, but try to limit those) will be a great forcing function that will require you to scour stackoverflow and the excellent PostgreSQL docs to learn many of the useful corners of SQL you'd never learn otherwise.

> This may be more intuitive for some developers, especially those that don't use SQL all the time. I tend to recommend my famous talk to such developers: [VIDEO]

This talk ("How Modern SQL Databases Come up with Algorithms that You Would Have Never Dreamed Of by Lukas Eder" [VIDEO] ) is not particularly gripping, but he does claim that modern database engines will ignore indexes if they estimate it will be faster to read all the data than it is to access the index first then read the relevant data. And that Oracle can have multiple execution plans and switch between them mid-query if the first one isn't working out as expected. Could this be a rare case of the mythical sufficiently smart compiler having more information at runtime than the programmer has at coding time, and that if you could hint which index to use, the trade off would be that you'd instead be troubleshooting queries which end up slower because of it?

> further, afaik there's no assignment nor iteration in SQL That was until CTEs were introduced in SQL:1999 > it's not a programming language at all. It's a.. query language. The two are not mutually exclusive. SQL is used to tell a computer what to do, and it is very powerful at it: [VIDEO]

>Totally agree. Lukas Eder has some nice presentations about it. Thanks for the shout out! For the record, that's probably the referenced talk: [VIDEO]