Also, in no way does SQL hide anything - it’s a declarative language, and will produce exactly what you tell it to, provided you understand what it is you asked it to do. The query engine is somewhat of a black box, but that is completely orthogonal.
Not really sure what you’re trying to argue here.
That’s the point. In an imperative language if you don’t yet understand (or make a typo, or whatever), you can just print/console.log and find out.
I’ve seen junior devs, data analysts, and LLMs spin their wheels trying to figure out why adding a join isn’t producing the output they want. I don’t think they would figure it out using SQL alone if you gave them a month.
Depending on how you write your query and how you structure your data, a query can take 0.005 seconds or 500 seconds.
SQL hiding the execution is an extremely leaky abstraction. To get the performance you need, you have to plan your possible queries in advance together with how to structure the data.
I mean, it doesn't matter if you only have 100 rows per table, but once you're dealing with multiple tables with millions of rows each it's everything.
But you're not prevented from finding out how your query was executed. For example EXPLAIN (MySQL, Postgres) or query analyser for MSSQL.
Ha ha, no, SQL implementations can conform to the standard in unexpected ways.
NULL = NULL
Is that true or false? We didn't know until 2003.
The SQL2003 changes were more about how constraints should treat NULL than anything intrinsic about NULL itself.