Hur man skriver SQL-frågor med AI

Stora språkmodeller lärde sig SQL från enorma mängder offentlig kod, dokumentation och fråge- och svarsforum, så de är bra på att producera syntaktiskt giltiga frågor. Vad de inte kan veta är din databas. Utan ditt schema gissar en modell tabellnamn som "users" eller "orders" och kolumnnamn som "created_at", och frågan kan misslyckas eller, ännu värre, köra och returnera fel svar. Den enskilt största förbättringen du kan göra är att klistra in schemat: CREATE TABLE-satser, eller en lista med tabeller, kolumner, datatyper och hur tabeller relaterar till främmande nycklar. Att lägga till några exempelrader och anteckningar om affärsregler, som "avbrutna beställningar har status = 'X'" eller "belopp lagras i cent", förhindrar många tysta fel. Ange SQL-dialekten också. PostgreSQL, MySQL, SQL Server, SQLite, BigQuery och Snowflake skiljer sig åt i datumfunktioner, strängsammansättning, LIMIT kontra TOP och andra detaljer. En fråga skriven för en kan misslyckas eller bete sig annorlunda på en annan. Ett tillförlitligt arbetsflöde har fyra steg: ge sammanhang, ställ frågan på vanlig engelska, be modellen förklara sin fråga i ord och testa sedan. Förklaringssteget är viktigt eftersom det avslöjar missförstånd, som att räkna rader istället för distinkta kunder eller använda en INNER JOIN som tyst släpper kunder som inte har några beställningar. Vanliga missuppfattningar inkluderar att tro att en fråga som körs är korrekt (en felaktig koppling kan dubbelräkna summor), att AI-utdata är säker att köra på produktion (en UPDATE eller DELETE utan en WHERE-sats ändras varje rad), och att du måste dela riktig data. Vanligtvis räcker bara schemat, vilket också håller kundinformation borta från chatten. Allmänna assistenter som ChatGPT, Claude och Gemini, kodningsverktyg som GitHub Copilot och AI-hjälparna inbyggda i många databasredigerare fungerar alla bäst med samma mönster.