5 ms·

I'm always amazed by those comments. Why couldn't you buy a book on SQL[0], and spend a week on it? Or just go over to YouTube for a refresher? [0]: Like https

I'm always amazed by those comments. Why couldn't you buy a book on SQL[0], and spend a week on it? Or just go over to YouTube for a refresher? [0]: Like https://www.oreilly.com/library/view/sql-queries-for/9780134858432/ https://www.oreilly.com/library/view/sql-queries-for/9780134...

ctxc 5mo ago
When you have a general idea of what smells bad vs what's okay...why? I'd rather get it from the LLM and review
Daishiman 5mo ago
This is fine for a moderately sized query. When your queries start taking in 8 joins and 20 fields per table because you're running queries on Presto with 5 TB of data, not only is it drastically better at writing (because it doesn't mess up the fields), you can ask it to try the query 5 different ways to help you land on the most optimal.
- dingaling 5mo ago
  This is a great example of AI tech-debt and fragility. An eight-join query is going to be nigh on unmaintainable should the requirements change, leading to a change-break-change-break spiral as your preferred coding agent tries to fix its previous fixes. Maybe the wise way to use AI would be to sort out the schema.
  - array_key_first 5mo ago
    This feels wrong. 8 joins is almost certainly reporting stuff, not transactional. Contrary to what some SQL-averse devs think, 300 lines of SQL is actually more maintainable than the equivalent ~1000 lines of application code. It's also much faster. And I do think that's the real conversion, because SQL is a much higher level language than currently available application languages. It's also declarative in nature, which helps maintainance. A highly normalized DB can easily end up with 8 joins required for some function. That's really not out of the question. "Sorting out" the schema then would be... denormalization, which is a thing, but you need to know why you're doing it. And I think 8 joins isn't enough of a reason.
    - darkwater 5mo ago
      Yes but developers (or at least web backend developers, who are the ones I interact with the most) are extremely averse to SQL and normalization.
      - marshray 5mo ago
        I think that's what was meant by "reporting stuff, not transactional".
- zelphirkalt 5mo ago
  That's exactly where I would expect it to fail somewhere, changing some part of the query every time it writes one.
  - dcrazy 5mo ago
    In my experience, Claude (at least Opus and Sonnet) is pretty good about not misremembering itself. I think you may be describing the experience of 6-12 months ago.
suttontom 5mo ago
I'm amazed you think that instead of using an LLM that someone will go buy a book and spend a week learning something that, judging by the fact that they last used it 30 years ago, likely won't be relevant for them soon.
- vintermann 5mo ago
  It's not only that I rarely use it, it's also that it's ugly. It's Relational Cobol. It's as loveable as Oracle. The vendor specific dialects don't even agree on how to do recursive queries do they? Unfortunately I am very good at forgetting things I resented having to learn, and SQL is definitively one of them.
  - nevertoolate 5mo ago
    So you don’t understand what you generate with ai and think that it will be a solution for a problem you can only solve using sql.
    - vintermann 5mo ago
      No, it's easy enough to understand the query once the AI has generated it. I have looked up how to do it many times after all.
      - nevertoolate 5mo ago
        Yes
    - jazzyjackson 5mo ago
      If the AI's query pulled what I intended to pull, why should I care to understand the SQL any more than I should understand the Query Plan or the Machine Code?
      - alternatex 5mo ago
        As with regex, querying is about not getting what you don't want as much as it is about getting what you want. And the former of the two is much more difficult to verify.
te_chris 5mo ago
Extremely weird take.
flir 5mo ago
SQL is (was?) one of my strongest skills, I enjoy it a lot, and I still reach for the LLM. It's just faster than me, and when it goes wrong (rarely) I can correct it in plain English.
wartywhoa23 5mo ago
Simple, because books don't earn OpenAI and Anthropic a dime.
timacles 5mo ago
A book on .... SQL? What is this, the 1970s?

ctxc 5mo ago

When you have a general idea of what smells bad vs what's okay...why? I'd rather get it from the LLM and review

Daishiman 5mo ago

This is fine for a moderately sized query. When your queries start taking in 8 joins and 20 fields per table because you're running queries on Presto with 5 TB of data, not only is it drastically better at writing (because it doesn't mess up the fields), you can ask it to try the query 5 different ways to help you land on the most optimal.

dingaling 5mo ago
This is a great example of AI tech-debt and fragility. An eight-join query is going to be nigh on unmaintainable should the requirements change, leading to a change-break-change-break spiral as your preferred coding agent tries to fix its previous fixes. Maybe the wise way to use AI would be to sort out the schema.
- array_key_first 5mo ago
  This feels wrong. 8 joins is almost certainly reporting stuff, not transactional. Contrary to what some SQL-averse devs think, 300 lines of SQL is actually more maintainable than the equivalent ~1000 lines of application code. It's also much faster. And I do think that's the real conversion, because SQL is a much higher level language than currently available application languages. It's also declarative in nature, which helps maintainance. A highly normalized DB can easily end up with 8 joins required for some function. That's really not out of the question. "Sorting out" the schema then would be... denormalization, which is a thing, but you need to know why you're doing it. And I think 8 joins isn't enough of a reason.
  - darkwater 5mo ago
    Yes but developers (or at least web backend developers, who are the ones I interact with the most) are extremely averse to SQL and normalization.
    - marshray 5mo ago
      I think that's what was meant by "reporting stuff, not transactional".
zelphirkalt 5mo ago
That's exactly where I would expect it to fail somewhere, changing some part of the query every time it writes one.
- dcrazy 5mo ago
  In my experience, Claude (at least Opus and Sonnet) is pretty good about not misremembering itself. I think you may be describing the experience of 6-12 months ago.

suttontom 5mo ago

I'm amazed you think that instead of using an LLM that someone will go buy a book and spend a week learning something that, judging by the fact that they last used it 30 years ago, likely won't be relevant for them soon.

vintermann 5mo ago
It's not only that I rarely use it, it's also that it's ugly. It's Relational Cobol. It's as loveable as Oracle. The vendor specific dialects don't even agree on how to do recursive queries do they? Unfortunately I am very good at forgetting things I resented having to learn, and SQL is definitively one of them.
- nevertoolate 5mo ago
  So you don’t understand what you generate with ai and think that it will be a solution for a problem you can only solve using sql.
  - vintermann 5mo ago
    No, it's easy enough to understand the query once the AI has generated it. I have looked up how to do it many times after all.
    - nevertoolate 5mo ago
      Yes
  - jazzyjackson 5mo ago
    If the AI's query pulled what I intended to pull, why should I care to understand the SQL any more than I should understand the Query Plan or the Machine Code?
    - alternatex 5mo ago
      As with regex, querying is about not getting what you don't want as much as it is about getting what you want. And the former of the two is much more difficult to verify.

te_chris 5mo ago

Extremely weird take.

flir 5mo ago

SQL is (was?) one of my strongest skills, I enjoy it a lot, and I still reach for the LLM. It's just faster than me, and when it goes wrong (rarely) I can correct it in plain English.

wartywhoa23 5mo ago

Simple, because books don't earn OpenAI and Anthropic a dime.

timacles 5mo ago

A book on .... SQL? What is this, the 1970s?