4 ms·

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

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.

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.