Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting AI to write good SQL

cloud.google.com

Post reply on HN
Print view View original

351–360 of 379 posts

Re: Getting AI to write good SQL

#351

Post by scottmf »

roflyear wrote: post #316
tonyhart7 wrote: post #124

Earlier quoted context omitted.

they would replace entire software department until AI make bug because endless changes into your javascript framework then they would hire human again to make fix we literally creating solution for our own problem

Or, just let their users deal with the bugs b/c churn will be less than the cost of developers.

Right. Look at Electron apps. They're ubiquitous despite the poorer performance and user experience because the benefits outweigh the negatives.

Maintaining a codebase isn't going to be a thing in the future, at least not in the traditional/current sense.

Re: Getting AI to write good SQL

#352

Post by [deleted] »

codr7 wrote: post #212
Kiro wrote: post #161

Earlier quoted context omitted.

You're the one doing the gaslighting now. "It doesn't work for me, therefore it can't possibly work for anyone else."

Which is a very reasonable conclusion given the kinds of errors it makes. Why are you so defensive about the tech? Involved in any AI startups, perhaps?

[deleted]

Re: Getting AI to write good SQL

#353

Post by senko »

CommenterPerson wrote: post #324

SQL Data analyst with years and years of experience here. Most of my roles were in small teams building quick ad-hoc analyses for business leaders in large multi billion dollar businesses. Example, one db was Oracle e-business suite. It had been set up ~20 years prior with enhancements along the way. There were only a handful of people in the company who knew what the fields helpfully named like ATTR_000349857. Every…

> Oracle e-business suite [...] set up ~20 years prior

> fields helpfully named like ATTR_000349857

> Everyone was overworked

> no one bothered to spend time on documenting the database.

I can't blame AI for not being helpful here, nothing short of divine intervention can fix that.

Re: Getting AI to write good SQL

#354

Post by 59nadir »

oplorpe wrote: post #323
squidbeak wrote: post #314

Earlier quoted context omitted.

I'm unsure I fully understand your contention. Are you suggesting that a rush to hyperbole which you don't like means advances in a technology aren't groundbreaking? Or is it that if there is more than one impressive advance in a technology, any advance before the latest wasn't worthy of admiration at the time?

Yes, it’s the hyperbole. This is, at best, an incremental development of an existing technology. Though even that is debatable considering the wildly differing opinions in this thread in regards to this vs other models.

About 1.5-2 years ago I was using GitHub Copilot to write code, mostly as a boilerplate completer, really, because eventually I realized I spent too much time reading the suggestions and/or fixing the end result when I should've just written it completely myself. I did try it out with a pretty wide scope, i.e. letting it do more or less and seeing what happened. All in all it was pretty cool, I definitely felt like there were some magic moments where it seems to put everything together and sort of read my mind.

Anyway, that period ended and I went until a few months ago without touching anything like this and I was hearing all these amazing things about using Cursor with Claude Sonnet 3.5, so I decided to try it out with a few use cases:

1. Have it write a tokenizer and parser from scratch for a made up Clojure-like language

2. Have it write the parser for the language given the tokenizer I had already written previously

3. Have it write only single parsing functions for very specific things with both the tokenizer and parsing code to look at to see how it works

#1 was a complete and utter failure, it couldn't even put together a simple tokenizer even if shown all of the relevant parts of the host language that would enable a reasonable tokenizer end result.

#2 was only slightly better, but the end results were nowhere near usable, and even after iteration it couldn't produce a runnable result.

#3 is the first one my previous experience with Copilot suggested to me should be doable. We started out pretty badly, it misunderstood one of the tokenizer functions it had examples for and used it in a way that doesn't really make sense given the example. After that it also wanted to add functions it had already added for some reason. I ran into myriad issues with just getting it to either correct, move on or do something productive until I just called it quits.

My personal conclusion from all of this is that yes, it's all incredibly incremental, any kind of "coding companion" or agent has basically the same failure modes/vectors they had years ago and much of that hasn't improved all that much.

The odds that I could do my regular work on 3D engines with the coding companions out there are slim to none when it can't even put together something as simple as a tokenizer together, or use an already existing one to write some simple tokenizer functions. For reference I know that it took my colleague who has never written either of those things 30 minutes until he productively and correctly used exactly the same libraries the LLM was given.

Re: Getting AI to write good SQL

#355

Post by Closi »

noosphr wrote: post #102
Closi wrote: post #87

Earlier quoted context omitted.

If that’s the scenario, I would be asking why the testing pipeline didn’t catch this rather than why was the AI SQL wrong.

Because the testing pipeline isn't the real database. Anyone that knows a database well can bring it down with a innocent looking statement that no one else will blink at.

Sure, but everyone knows humans end up bringing down the database too by writing an innocent looking test query nobody else blinks at, which is why you end up needing a testing strategy for ANY SQL before YOLO'ing into prod.

Re: Getting AI to write good SQL

#356

Post by johnthescott »

flysand7 wrote: post #11
mousetree wrote: post #6

Out of all the AI tools and models I’ve tried, the most disappointing is the Gemini built into BigQuery. Despite having well named columns with good descriptions it consistently gets nowhere close to solving the problem.

Having written more SQL than any other programming language by now, every time I've tried to use AI to write the query for me, I'd spend way more time getting the output right than if I'd just written it myself. As a quick aside there's one thing I wish SQL had that would make writing queries so much faster. At work we're using a DSL that has one operator that automatically generates joins from foreign key columns, j…

In PostgreSQL i tend to use NATURAL JOINs in the FROM clause to whittle down the distracting joins in the more relavent WHERE clause.

Re: Getting AI to write good SQL

#357

Post by ljm »

Spivak wrote: post #226
tclancy wrote: post #112

Earlier quoted context omitted.

Mother of God. I can write JSON instead of a language designed for querying. What is the advantage? If I’m going to move up an abstraction layer, why not give me natural language? Lots of things turn a limited natural language grammar into SQL for you. What is JSON going to {do: for: {me}}?

I find it funny people are making fun of this while every ORM builds up an object representing the query and then compiles it to SQL. SQL but as a data structure you can manipulate has thousands of implementations because it solves a real problem. This time it's because LLMs have an easier time outputting complex JSON than SQL itself.

Something still has to convert the JSON to SQL but in this case, who is writing the JSON? An LLM?

Sometimes, it's easier or more efficient to just learn the shit you're working with instead of spending 1000x the compute fobbing it off to OpenAI. Even just putting a blob of SQL in a heredoc and using a prepared statement to parameterise it is good enough.

Beyond that, query building is just part of the functionality an ORM provides. The main chunk of it is the mapping of DB-level data structures to app-level models and vice-versa, particularly in an OOP context.

Re: Getting AI to write good SQL

#358

Post by ljm »

mritchie712 wrote: post #77
fhkatari wrote: post #16

Earlier quoted context omitted.

You move all the tools to debug and inspect slow queries, in a completely unsupported JSON environment, with prompts not to make up column names. And this is progress?

The JSON compiles to SQL. Have you used a semantic layer? You might have a different opinion if you tried one.

    SELECT email FROM users WHERE deleted_at IS NOT NULL OR status = 'active'
seems more semantic to me at first glance than piping this into a JSON->SQL library

    {
      "_select": "email",
      "_table": "users",
      "_where": { 
        "deleted_at": { "_is": { "_not": SQL_NULL_VALUE } },
        "_or": [
          { "status": "inactive" },
        ]
      }
    }
which is usually how these things end up looking.

Re: Getting AI to write good SQL

#359

Post by BeFlatXIII »

oplorpe wrote: post #320
ayrtondesozzla wrote: post #312

Earlier quoted context omitted.

I'm not an LLM proselytiser but this makes no sense? It would almost make sense if someone were claiming there are only two possible games, the old one and the new one, and never any more. Who claims that?

I suppose my point is along these lines. When gpt3 was trained, its parent company refused to release the weights claiming it was a “clear and present danger to civilization”. Now GPT3 is considered a discardable toy. So either these things are going toward an inflection point of usefulness or this release too will be, in time, mocked as a discardable toy too. So why every 3 days do we get massive threads with people…

> When gpt3 was trained, its parent company refused to release the weights claiming it was a “clear and present danger to civilization”. Now GPT3 is considered a discardable toy.

That was just the cover story for being greedy with the data.

Re: Getting AI to write good SQL

#360

Post by jstummbillig »

oplorpe wrote: post #320
ayrtondesozzla wrote: post #312

Earlier quoted context omitted.

I'm not an LLM proselytiser but this makes no sense? It would almost make sense if someone were claiming there are only two possible games, the old one and the new one, and never any more. Who claims that?

I suppose my point is along these lines. When gpt3 was trained, its parent company refused to release the weights claiming it was a “clear and present danger to civilization”. Now GPT3 is considered a discardable toy. So either these things are going toward an inflection point of usefulness or this release too will be, in time, mocked as a discardable toy too. So why every 3 days do we get massive threads with people…

That is fairly easily explained: Imagine there existed a trick that (you think) ups your productivity by 10% every other week without you having to do, well, anything. It does not matter where the floor was, and there seems to be no ceiling. The trick was really good the first time and it continues to be good every time.
Post reply on HN