Vibe-koodaus on tehnyt ohjelmoinnista nopeampaa kuin koskaan. Cursor-tekoäly ja muut koodausautomaatio-työkalut mahdollistavat SaaS MVP -sovelluksen rakentamisen päivissä viikkojen sijaan.
Tämä nopeus tuo mukanaan suuren riskin. Kun tekoälyohjelmointi kohtaa tietokannan, tuloksena on usein hallitsematon kaaos.
Tekoäly ei ymmärrä tietokantasi nykyistä tilaa tai tuotantodatasi arvoa. Jos annat Cursorin luoda ja ajaa tietokantamigraatiot vapaasti, päädyt ennen pitkää rikkinäisiin skeemoihin ja kadonneeseen dataan.
Tässä oppaassa rakennamme pomminvarman arkkitehtuurin ja työnkulun, jolla hallitset Drizzle ORM -migraatioita Cursorilla ilman pelkoa datakadosta.
---
Arkkitehtuuri: Hallitun migraation elinkaari
Turvallinen tietokantakehitys tekoälyn kanssa vaatii tiukan työnjaon. Cursor hoitaa koodin ehdottamisen, Drizzle ORM hoitaa skeeman määrittelyn, ja sinä hoidat kontrollin.
Seuraava arkkitehtuurikaavio kuvaa, miten muutokset etenevät ideasta tietokantaan:
[ Cursor-tekoäly ]
│ (Ehdottaa muutoksia vain schema.ts-tiedostoon)
▼
[ Drizzle-tietokantaschemat ]
│ (Kehittäjä ajaa: drizzle-kit generate)
▼
[ SQL-migraatiotiedosto ] ───► [ Manuaalinen katselmointi ]
│
▼ (Hyväksytty)
[ Supabase / Kohdetietokanta ]
Tässä mallissa Cursor ei koskaan pääse suoraan käsiksi tietokantaasi. Se ei myöskään kirjoita SQL-migraatiotiedostoja itse. Kaikki muutokset kulkevat Drizzle ORM -skeeman ja Drizzle Kit -työkalun kautta.
---
Vaihe 1: Eristä Cursorin oikeudet (System Prompt)
Ensimmäinen virhe on antaa Cursorille vapaat kädet muokata mitä tahansa tiedostoa projektissasi. Sinun on rajoitettava sen toiminta-alue pelkkiin skeematiedostoihin.
Luo projektisi juureen .cursorrules-tiedosto tai käytä Cursorin järjestelmäprompteja. Syötä sinne seuraava ohjeistus:
Cursor-järjestelmäohje tietokantamuutoksiin:
- Muokkaa tietokantarakenteita ainoastaan tiedostossa src/db/schema.ts (tai projektisi vastaavassa Drizzle-skeematiedostossa).
- Älä koskaan muokkaa drizzle/migrations-kansiossa olevia SQL-tiedostoja.
- Älä koskaan yritä ajaadrizzle-kit pushtaisupabase db push-komentoja suoraan terminaalissa ilman käyttäjän nimenomaista lupaa.
- Kun teet muutoksia skeemaan, selitä lyhyesti, mitä muutit ja miksi.
Tämä yksinkertainen sääntö estää tekoälyä luomasta omia, epästandardeja SQL-ratkaisujaan migraatiokansioosi.
---
Vaihe 2: Promptausmalli skeemamuutoksiin
Kun haluat lisätä uuden ominaisuuden, älä pyydä Cursoria "päivittämään tietokantaa". Pyydä sitä muokkaamaan Drizzle-skeemaa tarkasti määritellyillä säännöillä.
Käytä tätä promptimallia Cursorin chatissa:
Haluan lisätä sovellukseen uuden ominaisuuden: [kuvaile ominaisuus, esim. tiimituki].
Päivitä schema.ts-tiedosto Drizzle ORM -syntaksilla seuraavasti:
1. Luo tarvittavat uudet taulut ja relaatiot.
2. Käytä olemassa olevia nimeämiskäytäntöjä (esim. camelCase tai snake_case).
3. Varmista, että kaikilla uusilla kentillä on asianmukaiset tyypit ja NOT NULL -määritteet, jos ne ovat pakollisia.
4. Älä poista tai muuta olemassa olevia kriittisiä kenttiä ilman varoitusta.
Kun Cursor ehdottaa muutoksia schema.ts-tiedostoon, hyväksy ne vasta, kun olet varmistanut, että tyypitykset ja viite-eheydet näyttävät loogisilta.
---
Vaihe 3: Migraation generointi ja tarkistus
Kun tietokantaschemat on päivitetty TypeScript-tasolla, on aika siirtää muutokset SQL-muotoon. Älä anna Cursorin tehdä tätä vaihetta.
Aja omassa terminaalissasi seuraava komento:
npx drizzle-kit generate
Tämä komento vertaa schema.ts-tiedostoa edellisiin migraatioihisi ja luo uuden SQL-tiedoston drizzle-kansioon.
Nyt astuu kuvaan tärkein vaihe: SQL-tiedoston manuaalinen tarkistus. Avaa luotu .sql-tiedosto ja etsi seuraavia vaaran merkkejä:
- DROP TABLE tai DROP COLUMN: Jos Drizzle yrittää poistaa sarakkeen, jota tarvitset, pysäytä prosessi. Tämä tapahtuu usein, jos olet nimennyt sarakkeen uudelleen.
- Puuttuvat oletusarvot (DEFAULT): Jos lisäät uuden
NOT NULL-sarakkeen olemassa olevaan tauluun ilman oletusarvoa, migraatio epäonnistuu tuotannossa, koska vanhoilla riveillä ei ole arvoa tälle kentälle.
---
Vaihe 4: Turvallinen ajo Supabase-ympäristöön
Kun käytössä on Supabase, paikallinen kehitys ja tuotanto on pidettävä tiukasti erillään. Älä koskaan aja migraatioita suoraan tuotantotietokantaan kehityksen aikana.
Suositeltu työnkulku SaaS MVP -projekteissa:
1. Paikallinen testaus: Aja migraatiot ensin paikalliseen Docker-pohjaiseen Supabase-instanssiin tai erilliseen kehitystietokantaan.
npx drizzle-kit migrate
2. Testaa sovellusta: Varmista, että Cursorilla rakennettu sovellus toimii paikallisesti uuden skeeman kanssa.
3. Tuotantovienti: Kun olet varma toimivuudesta, aja migraatiot tuotantoon hallitusti CI/CD-putken kautta tai manuaalisesti suojatulla yhteysmerkkijonolla.
---
Vältä nämä kolme sudenkuoppaa
1. "Drizzle-kit push" -komennon väärinkäyttö: drizzle-kit push synkronoi skeeman suoraan tietokantaan ilman migraatiotiedostoja. Se on kätevä nopeaan prototyyppaukseen, mutta tuhoisa tuotannossa. Käytä aina tiedostopohjaisia migraatioita (generate ja migrate).
2. Skeematiedoston pirstaloituminen: Jos projektisi kasvaa, älä anna Cursorin luoda kymmeniä eri skeematiedostoja sinne tänne. Pidä tietokantaschemat keskitetysti yhdessä kansiossa (esim. src/db/schema/), jotta Drizzle löytää ne aina luotettavasti.
3. Tekoälyn luomat indeksit: Cursor tykkää lisätä indeksejä jokaiseen mahdolliseen sarakkeeseen "suorituskyvyn parantamiseksi". Liialliset indeksit hidastavat kirjoitusoperaatioita. Lisää indeksejä vain sarakkeisiin, joilla tehdään usein hakuja (kuten foreign keys tai slug).
---
Pidä ohjat omissa käsissäsi
Vibe-koodaus tekee sovelluskehityksestä hauskaa ja uskomattoman tehokasta. Tietokanta on kuitenkin sovelluksesi sydän – sen kohdalla ei ole varaa "vibeillä".
Kun pidät Cursorin tiukasti skeematiedoston muokkaajana ja jätät migraatioiden generoinnin sekä ajamisen Drizzle Kitin ja oman valvontasi alle, säästät itsesi tuntien vianetsinnältä ja menetetyiltä yöunilta.
Mikä on ollut suurin haasteesi tekoälyn ja tietokantojen yhteispelissä? Oletko jo kokeillut Drizzlen ja Cursorin yhdistelmää omassa projektissasi?