3 ms·

Frankly, this is terrible advice. If you’re not designing your data model around the language it’s going to be queried in, how do you expect to get decent perfo

Frankly, this is terrible advice. If you’re not designing your data model around the language it’s going to be queried in, how do you expect to get decent performance out of the database? 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.

paulddraper 1y ago
SQL is a declarative language so it —- by definition —- hides the execution. Not really sure what you’re trying to argue here.
- sgarland 1y ago
  Parent made it sound - to me - that you put an input in and hope for the best. If you understand the operators, you can quite confidently predict an output given an input.
  - halfcat 1y ago
    > If you understand the operators 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.
    - SkiFire13 1y ago
      The equivalent of `print`/`console.log` in SQL would be using subqueries/CTE and run them to see the intermediate result (just like `print`/`console.log` show you intermediate results of the executions in an imperative language).
    - sgarland 1y ago
      Then you back off, and go back to first principles. Create the minimum example of the problem, and as a sibling comment mentioned, break it down to its constituent parts and observe what happens in each.
- crazygringo 1y ago
  You missed the "performance" part. 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.
  - greekrich92 1y ago
    If you use bubblesort instead of quicksort it will take longer as well. Knowing the language and understanding the schema solves this.
- teh_klev 1y ago
  >hides the execution. But you're not prevented from finding out how your query was executed. For example EXPLAIN (MySQL, Postgres) or query analyser for MSSQL.
chasil 1y ago
> Also, in no way does SQL hide anything - it’s a declarative language, and will produce exactly what you tell it to. 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. https://en.wikipedia.org/wiki/Null_(SQL)#Criticisms https://en.wikipedia.org/wiki/Null_(SQL)#Criticisms
- gfody 1y ago
  that's not true or false it's null
- sgarland 1y ago
  Considering that all implementations I’m aware of have evaluated that expression to NULL, this isn’t a very pragmatic example. NULL is unknown, and every type has it as a possibility. The SQL2003 changes were more about how constraints should treat NULL than anything intrinsic about NULL itself.

paulddraper 1y ago

SQL is a declarative language so it —- by definition —- hides the execution. Not really sure what you’re trying to argue here.

sgarland 1y ago
Parent made it sound - to me - that you put an input in and hope for the best. If you understand the operators, you can quite confidently predict an output given an input.
- halfcat 1y ago
  > If you understand the operators 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.
  - SkiFire13 1y ago
    The equivalent of `print`/`console.log` in SQL would be using subqueries/CTE and run them to see the intermediate result (just like `print`/`console.log` show you intermediate results of the executions in an imperative language).
  - sgarland 1y ago
    Then you back off, and go back to first principles. Create the minimum example of the problem, and as a sibling comment mentioned, break it down to its constituent parts and observe what happens in each.
crazygringo 1y ago
You missed the "performance" part. 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.
- greekrich92 1y ago
  If you use bubblesort instead of quicksort it will take longer as well. Knowing the language and understanding the schema solves this.
teh_klev 1y ago
>hides the execution. But you're not prevented from finding out how your query was executed. For example EXPLAIN (MySQL, Postgres) or query analyser for MSSQL.

chasil 1y ago

> Also, in no way does SQL hide anything - it’s a declarative language, and will produce exactly what you tell it to. 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. https://en.wikipedia.org/wiki/Null_(SQL)#Criticisms https://en.wikipedia.org/wiki/Null_(SQL)#Criticisms

gfody 1y ago
that's not true or false it's null
sgarland 1y ago
Considering that all implementations I’m aware of have evaluated that expression to NULL, this isn’t a very pragmatic example. NULL is unknown, and every type has it as a possibility. The SQL2003 changes were more about how constraints should treat NULL than anything intrinsic about NULL itself.