Ano ang ORM? Paano Nakikipag-usap ang mga App sa Database, Ipinaliwanag

Ang ORM (object-relational mapper) ay isang code library na nasa pagitan ng app at ng relational database. Sa halip na sumulat ng database queries sa SQL, nagtatrabaho ang developer sa datos bilang ordinaryong object sa programming language nila, gaya ng db.booking.create(...) o Booking.find(...). Isinasalin ito ng ORM sa SQL, pinapatakbo, at ibinabalik ang resulta bilang mga object. Kabilang sa mga sikat na halimbawa ang Prisma at Drizzle para sa TypeScript, SQLAlchemy para sa Python, at Entity Framework Core para sa C#.

Bakit mahalaga ang ORM kapag gumagawa ka gamit ang AI

Kapag nagdagdag ang AI app builder ng database sa app mo, kadalasan ay nagdadagdag din ito ng ORM para makipag-usap dito. Hindi mo kailangang sumulat ng ORM code, pero makakatulong na malaman mong nandiyan ito:

• Nasa code ang data model mo. Kadalasan, ang schema file ng ORM ang pinakamalinaw na paglalarawan ng datos ng app mo: anong mga table ang umiiral, anong field ang bawat isa, at paano sila nagkakaugnay. Ang pagbabasa nito ay mabilis na paraan para makita kung naintindihan ng AI ang app mo.
• Dumadaan sa migrations ang mga pagbabago sa database. Kapag humiling ka ng "magdagdag ng phone number sa mga customer", ina-update ng AI ang model at gumagawa ng migration. Makakatulong ang kaalamang ito para maintindihan kung bakit kailangang ma-apply muna ang isang pagbabago bago ito gumana nang live.
• Ligtas bilang default. Gumagawa ang ORM ng queries sa paraang nagpoprotekta laban sa SQL injection, isa sa pinakakaraniwang security hole sa mga app na manual na bumubuo ng query.
• Mga bitag sa bilis. Madaling makapagpatakbo ang ORM ng daan-daang maliliit na query kung saan sana isa lang ang kailangan. Karaniwang dahilan ito ng mabagal na page sa mga app na gawa ng AI.

Isang pang-araw-araw na paghahambing

Isipin ang isang turistang Briton at isang shopkeeper sa Japan na walang iisang wika, at nag-uusap sila sa pamamagitan ng interpreter.

Sabi ng turista (ang app mo), "Gusto ko ang tatlong pinakamurang tsaa ninyo." Isinasalin ito ng interpreter (ang ORM) sa tumpak na Hapon (SQL), ipinapasa sa shopkeeper (ang database), at isinasalin pabalik ang sagot sa Ingles.

Hindi natututo ang turista ng Hapon, at para sa karaniwang usapan ay okay lang iyon. Pero sa mas kumplikadong negosasyon, mas mainam magsalita nang direkta, kaya karamihan ng ORM ay nagpapahintulot sa developer na sumulat ng raw SQL kapag kailangan.

Paano gumagana ang ORM

Ang mga database gaya ng Postgres ay nag-iimbak ng datos sa tables na may rows at columns, at kino-query gamit ang SQL. Ang mga programming language naman ay nagtatrabaho sa objects: isang booking na may date, customer at status. Ang ORM ang nagmamapa sa dalawa:

Ang apat na operasyong ito ang mga CRUD na aksyon na halos lahat ng app ay nakabatay.

Isang worked example: mga booking gamit ang Prisma

Narito ang pinasimpleng Prisma schema para sa isang salon booking app. Naglalarawan ito ng dalawang table at kung paano sila konektado:

model Customer {
  id       Int       @id @default(autoincrement())
  name     String
  email    String    @unique
  bookings Booking[]
}

model Booking {
  id         Int      @id @default(autoincrement())
  startsAt   DateTime
  service    String
  customer   Customer @relation(fields: [customerId], references: [id])
  customerId Int
}

Sa simpleng salita: ang customer ay may pangalan, natatanging email, at maraming booking; ang bawat booking ay may oras ng simula, serbisyo, at kabilang sa isang customer.

Ngayon, gusto ng app ang "mga paparating na booking ni Lena, pinakamalapit muna":

const bookings = await db.booking.findMany({
  where: {
    customer: { email: "lena@example.com" },
    startsAt: { gte: new Date() },
  },
  orderBy: { startsAt: "asc" },
});

Isinasalin ito ng ORM sa SQL na humigit-kumulang ganito, pinapatakbo, at ibinabalik ang listahan ng booking objects:

SELECT b.* FROM "Booking" b
JOIN "Customer" c ON c.id = b."customerId"
WHERE c.email = $1 AND b."startsAt" >= $2
ORDER BY b."startsAt" ASC;

Ang $1 at $2 ay mga placeholder: ang email at petsa ay ipinapadala nang hiwalay sa teksto ng query, at iyon ang pumipigil sa SQL injection.

Migrations

Kung sunod mong hilingin ang "hayaang magdagdag ng phone number ang mga customer", idaragdag ng AI ang phone String? sa Customer model (ang ? ay nangangahulugang opsyonal) at gagawa ng migration, isang maliit na SQL script gaya ng ALTER TABLE "Customer" ADD COLUMN "phone" TEXT;. Naka-save ang mga migration nang sunod-sunod, kaya maidadala ang bawat kopya ng database sa parehong istruktura, at nananatili ang kasaysayan ng mga pagbabago.

Karaniwang ORM ayon sa wika

Iba-iba ang antas ng pagtatago ng ORM sa SQL. Gumagamit ang Prisma ng sarili nitong schema language at estilo ng query; sinasadya ng Drizzle na manatiling malapit sa hugis ng SQL habang nananatiling typed ang lahat. Ang mas magagaan na kasangkapang tinatawag na query builders, gaya ng Knex o Kysely para sa TypeScript, ay tumutulong bumuo ng SQL sa code nang hindi minamapa ang rows bilang buong object.

Mahahalagang termino

Mga karaniwang maling akala

• "Ang ORM ay database." Hindi. Tagasalin ito. Kailangan mo pa rin ng database gaya ng Postgres.
• "Sa ORM, hindi mo na kailangang intindihin ang datos mo." Ang mga table na mahina ang disenyo ay nakakainis din kahit sa pamamagitan ng ORM. Mas mahalaga ang magandang data model kaysa sa tool.
• "Laging mabagal ang ORM." Okay lang ang karaniwang query. Kadalasan, galing ang bagal sa mga pattern gaya ng N+1 queries o kulang na indexes, at naaayos ang mga iyon.
• "Ibig sabihin ng ORM ay walang panganib ng SQL injection, kailanman." Ligtas ang karaniwang ORM methods, pero mapanganib pa rin ang raw SQL na may user input na idinikit.
• "Ang pag-edit ng schema file ay nagbabago sa live na database." Hindi, maliban kung nagawa na ang migration at na-apply na ito sa database na iyon.

Ano ang itatanong sa iyong AI builder

• "Ipakita mo ang database schema at ipaliwanag sa simpleng Ingles ang bawat table at relasyon."
• "Anong ORM ang ginagamit ng project na ito, at nasaan ang mga migration?"
• "Bago baguhin ang anumang table, sabihin mo kung maaapektuhan ang umiiral na datos, at huwag magbura ng column na may datos nang hindi nagtatanong muna."
• "Tingnan ang pinakamabagal na page para sa N+1 queries at magdagdag ng indexes kung saan sinasala o inaayos ang mga listahan."
• "Siguraduhing dumadaan sa ORM o gumagamit ng parameters ang bawat query na may user input. Walang SQL na binuo sa pamamagitan ng string."

Mga ORM sa Mythex

Kapag kailangang mag-save ng datos ng app mo, nagdadagdag ang Mythex ng nakalaang Postgres database sa project. Magtanong lang sa chat o gamitin ang /database na command. Isinasaksak nito ang connection details sa workspace at sa published app (Database). Ang agent na ang sumusulat ng code na bumabasa at nagse-save ng datos mo. Kung may kagustuhan ka, gaya ng "gamitin ang Prisma", "gamitin ang SQLAlchemy", o "plain SQL, walang ORM", sabihin mo ito sa chat. Hilingin mong ipaliwanag sa iyo ang schema kahit kailan mo gusto. Mababasa mo rin ang mga file sa code editor. Para sa mas malawak na larawan, tingnan ang ano ang database at SQL vs NoSQL.

Mga tanong