←back to thread

Getting AI to write good SQL

(cloud.google.com)
478 points richards | 3 comments | 16 May 25 21:10 UTC | HN request time: 0.202s | source
Show context
AdrianB1 ◴[16 May 25 23:20 UTC] No.44010668[source]▶
In real life I find using AI for SQL dangerous. It allows people that don't know what they do to write queries that can significantly impact servers. In my world databases are relatively big for most developers, but not huge.

Sometimes when I want to fine tune a query I am challenging AI to provide a better solution. I give it the already optimized query and I ask for better. I never got a better answer, sometimes because AI is hallucinating or because the changes that it proposes are not working in a way that is beneficial, it is like an idiot parrot is telling what it overheard in the brothel - good info if it is a war brothel frequented by enemy officers in 1916, but not these days.

replies(5): >>44010829 #>>44011104 #>>44011385 #>>44011554 #>>44011573 #
1. strict9 ◴[17 May 25 02:23 UTC] No.44011573[source]▶
It should never be at the point where some random person can impact a server.

That's what read replicas with read-only access are for. Production db servers should not be open to random queries and usage by people. That's only for the app to use.

replies(2): >>44013003 #>>44015070 #
2. AdrianB1 ◴[17 May 25 08:57 UTC] No.44013003[source]▶
How it should be and how it is, that depends on who is the decision maker. If the decision maker is a technical person, there is no gap, but in my case the decision maker is a non-technical manager with no competence to make such decisions, but that is the way the company is organized. So letting people use AI to dig through a 1 TB database is not a good idea, while not using AI prevents them to even try. Security by oblivion.
3. sgarland ◴[17 May 25 15:40 UTC] No.44015070[source]▶
Unless you have a much more regimented code review process than anywhere I've seen, "a random person" can impact prod quite easily by introducing a bad query into the app. Since ORMs are rampant, it's probably heavily obfuscated to begin with, so they won't even see the raw SQL. At best, they'll have run it on stage, where the DB size is probably so tiny that its performance issues go unnoticed.