Frågor som ”funkade fint” i dev har en obehaglig tendens att falla i staging. Joinar multiplicerar rader, NULL-värden smiter förbi filter, textkodningar skapar fel, och plötsligt stoppas releasen av data du inte planerade för. Det värsta är att du upptäcker det först efter att du redan har byggt funktionen kring strukturerad, orealistisk exempeldata.
Den här prompten för SQL test datasets är byggd för analytics engineers som validerar knepiga rapportfrågor före en lansering, QA-ansvariga som behöver adversarial-men-rimlig data för att reproducera buggar på beställning, och backendutvecklare som härdar databaslogik kring foreign keys, standardvärden och text i edge cases. Utdata är en sammanfattning med föranalys plus ett set SQL-INSERT-script som innehåller gränsvärden, skevhet, stökiga strängar, NULL-fällor och relationella ”fallgropar”, med anteckningar om vad varje batch är tänkt att ha sönder.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Det du får |
|---|---|---|
|
|
|
Hela AI-prompten: generator för edge-case SQL INSERT-testdata
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[KONTEXT] |
Ge en övergripande bild av situationen eller problemet som ska hanteras, inklusive relevant bakgrundsinformation. Till exempel: "Skapa syntetiska dataset för att testa brister i frågor i en e-handelsdatabas med tabeller för användare, beställningar och produkter."
|
|
[UTMANING] |
Beskriv den specifika utmaning eller det problem som datasetet behöver adressera, med fokus på kantfall eller besvärliga situationer. Till exempel: "Säkerställ att datasetet synliggör problem som långsamma joinar, brister i NULL-hantering och fel vid gränsvärden i frågor för finansiella transaktioner."
|
|
[AMNE] |
Ange datasetets huvudsakliga ämne eller fokusområde, till exempel en viss typ av fråga eller databasspecifikt beteende. Till exempel: "Testa referensintegritet och snedfördelade datadistributioner i ett schema för ett kundlojalitetsprogram."
|
|
[MAL_DATAVOLYM] |
Ange datasetets omfattning i antal poster eller storlek, anpassat efter de testscenarier som ska köras. Till exempel: "10 000 poster per tabell för att efterlikna produktionsliknande förhållanden, samtidigt som prestandatester av frågor hålls hanterbara."
|
|
[KRAV_PA_REFERENSINTEGRITET] |
Definiera begränsningar eller regler för hur relationer mellan tabeller ska upprätthållas, inklusive om avvikelser får förekomma i testsyfte. Till exempel: "Alla foreign key-begränsningar ska efterlevas strikt, med undantag för en mindre mängd föräldralösa poster för att testa kantfall."
|
|
[SQL_DIALEKT] |
Ange vilken SQL-dialekt som ska användas för att generera datasetet, baserat på den avsedda databasmotorn. Till exempel: "PostgreSQL med stöd för uppskjutna begränsningar och JSON-datatyper."
|
|
[PROBLEMFRAGOR] |
Lista specifika frågor eller frågetyper som är kända för att orsaka problem och som behöver testas mot det syntetiska datasetet. Till exempel: "En komplex rapportfråga som kombinerar kunddemografi och orderhistorik med flera joinar och filter."
|
Proffstips för bättre resultat från AI-prompten
- Klistra in schemat som om du briefade en människa. Ta med kolumntyper, standardvärden, check constraints och en snabb notis om vilka kolumner som är ”affärskritiska”. Till exempel: ”orders.status måste vara en av (‘pending’, ‘paid’, ‘refunded’), men historiska importer kommer ibland in som ‘PAYD’.” Sådana detaljer höjer datakvaliteten direkt.
- Ge dina index och unikhetsconstraints tidigt. Prompten frågar uttryckligen efter dem, och det spelar roll eftersom ”edge-case”-data ofta krockar med unikhet om det inte planeras. En bra uppföljning: ”Efter att du har genererat datasetet, lägg till en andra version som medvetet triggar unika constraint-brott på ett kontrollerat sätt, märkt per scenario.”
- Säg hur din värsta fråga ser ut. Klistra in den faktiska SQL:en (eller en förenklad version) som har varit instabil i staging, plus förväntade radantal. Be: ”Generera inserts som skulle få den här frågan att ge fel resultat om det finns en join-multipliceringsbugg, och förklara vilka rader som triggar den.”
- Iterera med ”skalreglage”, inte vaga volymönskemål. I stället för ”gör det större”, ange distributionsmål som: ”Skapa 1 000 kunder, men 15 ‘whales’ står för 60 % av orders; 2 % av orders har NULL i shipped_at; 5 % har icke-ASCII i notes.” Efter första utdata, prova att fråga: ”Gör nu alternativ 2 mer aggressivt vad gäller skevhet och håll alternativ 1 närmare typisk produktion.”
- Använd två dataset: ’giltigt’ och ’jobbigt men plausibelt’. Många team testar bara strikt integritet. Be om båda: ”Variant A måste uppfylla alla FK- och CHECK-constraints; Variant B får innehålla orphans och saknade valfria relationer, men märk varje bruten regel och håll scriptet körbart genom att ordna inserts och använda transaktioner.” Det här fångar ofta antaganden i applagret som du inte visste att du hade.
Vanliga frågor
Analytics engineers använder den för att generera inserts som avslöjar felaktiga joinar, duplicerade rader och aggregeringar som är ”tyst fel” innan dashboards går live. QA-ansvariga använder den för att bygga repeterbara staging-dataset som reproducerar buggar kopplade till NULL:er, kodningar och edge cases i constraints. Backendutvecklare använder den när de ändrar constraints, standardvärden eller foreign keys och vill se antaganden i applikationen fallera på ett säkert sätt. Data platform engineers har nytta av den för att testa inläsnings- och normaliseringslogik mot stökiga men plausibla indata.
E-handelsvarumärken använder den för att efterlikna verkliga ordermönster, som några få högvolymkunder, edge cases för returer/återbetalningar och adresssträngar som knäcker parsning. När rapporter styr lager- eller ekonomibeslut är ”nästan korrekt” SQL dyrt. SaaS-bolag använder den för prenumerationsstatusar, edge conditions som liknar proration och multi-tenant-joinar där ett dåligt antagande läcker data eller räknar fel på MRR. Fintech- och redovisningsteam använder den för gränsvärden, avrundning och liggare-liknande relationskedjor där en saknad parent-post eller en duplicerad join kan förstöra totaler. Marknadsplatser får värde av valfria relationer (köpare utan säljarmetadata, annonser utan bilder) som ofta knäcker applogik och rapportering.
En typisk prompt som ”Write me SQL insert statements for my tables” misslyckas eftersom den: saknar dina constraints, index och FK-beteenden, så datan blir antingen ogiltig eller för ”strukturerad” för att vara relevant; inte ger någon strukturerad föranalys, så den missar riskhotspots i frågorna som dina relationer antyder; ignorerar distribution och skevhet, vilket skapar jämn slump som inte triggar långsamma planer eller heavy-hitter-joinmönster; spottar ut generiska strängar som inte stressar kodningar, whitespace eller delimiter-finesser; och missar relationella felscenarier som parents utan children eller valfria länkar som är giltiga men överraskande.
Ja. Du anpassar den genom att ge den det den ber om: fullständiga schemadetaljer (tabeller, kolumner, typer, standardvärden), index och unikhetsconstraints, foreign keys med ON DELETE/UPDATE-beteende samt affärsregler och ”får-inte-hända”-villkor. Lägg även till kända felmoder (till exempel ”den här rapporten dubblar ibland intäkter”) så att den kan designa rader som specifikt triggar den typen av buggar. En bra uppföljning är: ”Generera Variant A (strikt integritet) och Variant B (kontrollerade integritetsbrott), och annotera vilka inserts som är avsedda att stressa NULL-hantering, kodning och join-multiplicitet.”
Det största misstaget är att ge ofullständiga schemadetaljer – i stället för ”users(id, email), orders(id, user_id),” klistra in typer, standardvärden, checks och unikhet som ”users.email VARCHAR(255) UNIQUE NOT NULL” och ”orders.user_id BIGINT REFERENCES users(id) ON DELETE SET NULL.” Ett annat vanligt fel är att utelämna index, vilket leder till dataset som inte speglar hur planeringen beter sig vid skevhet; inkludera ”idx_orders_user_id” och eventuella sammansatta index. Många glömmer också att dela affärsregler, så ”oväntat men giltigt” blir ”oväntat och omöjligt”; byt ”status kan vara vad som helst” mot ”status är ENUM plus legacy-värden som tillåts i importer.” Slutligen ber team om edge cases men förbjuder alla integritetsbrott utan att ange prioriteringar; om du behöver båda, be uttryckligen om två varianter och säg vilka regler som får böjas.
Den här prompten passar inte för engångsjobb där du bara behöver en pytteliten demodataset och inte tänker iterera på scenarier. Den passar också dåligt om du inte kan dela ens ett sanerat schema, eftersom kvaliteten beror på riktiga kolumntyper, constraints och relationer. Och om målet är riktig prestandabenchmarking behöver du dedikerad lasttestning och profilering i stället; använd detta för att först hitta korrekthetsproblem och ”överraskande” fel, och benchmarka sedan med produktionsliknande volymer.
Strukturerad exempeldata döljer exakt de buggar som sabbar releaser. Generera edge-case-inserts, kör dina riktiga frågor mot dem och åtgärda problemen medan det fortfarande är billigt.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.