Ի՞նչ է ORM-ը։ Ինչպես են հավելվածները խոսում տվյալների բազաների հետ, բացատրված

ORM-ը (օբյեկտ-ռելյացիոն քարտեզագրիչ) կոդի գրադարան է, որը գտնվում է հավելվածի և ռելյացիոն տվյալների բազայի միջև։ SQL-ով տվյալների բազայի հարցումներ գրելու փոխարեն մշակողները աշխատում են տվյալների հետ որպես սովորական օբյեկտներ իրենց ծրագրավորման լեզվով՝ db.booking.create(...) կամ Booking.find(...) ձևով, իսկ ORM-ը դա թարգմանում է SQL-ի, կատարում է այն և արդյունքները վերադարձնում օբյեկտների ձևով։ Հայտնի օրինակներ են TypeScript-ի համար Prisma-ն և Drizzle-ը, Python-ի համար SQLAlchemy-ն, իսկ C#-ի համար՝ Entity Framework Core-ը։

Ինչու են ORM-ները կարևոր, երբ կառուցում եք AI-ով

Երբ AI հավելվածների կառուցիչն ավելացնում է ձեր հավելվածին տվյալների բազա, սովորաբար ավելացնում է նաև ORM՝ դրա հետ խոսելու համար։ ORM-ի կոդ գրել ձեզ պետք չի գա, բայց օգտակար է իմանալ, որ այն կա․

• Ձեր տվյալների մոդելը գտնվում է կոդում։ ORM-ի սխեմայի ֆայլը հաճախ ձեր հավելվածի տվյալների ամենահստակ նկարագրությունն է՝ ո՞ր աղյուսակներն են գոյություն ունեն, յուրաքանչյուրն ի՞նչ դաշտեր ունի և ինչպես են կապված։ Դրա կարդալը արագ ձև է ստուգելու, թե արդյոք AI-ը ճիշտ է հասկացել ձեր հավելվածը։
• Տվյալների բազայի փոփոխությունները անցնում են միգրացիաներով։ Երբ խնդրում եք «ավելացրու հեռախոսահամար հաճախորդներին», AI-ը թարմացնում է մոդելը և ստեղծում միգրացիա։ Դա իմանալը օգնում է հասկանալ, թե ինչու որոշ փոփոխություն կարող է կիրառվել, նախքան այն կաշխատի կենդանի տարբերակում։
• Անվտանգություն՝ լռելյայն։ ORM-ները հարցումները կառուցում են այնպես, որ պաշտպանեն SQL ներարկումից (SQL injection), որը ձեռքով հավաքված հարցումներ ունեցող հավելվածների ամենատարածված անվտանգության խոցերից մեկն է։
• Արագության թակարդներ։ ORM-ները հեշտացնում են պատահաբար հարյուրավոր փոքր հարցումներ կատարելը այնտեղ, որտեղ բավական էր մեկը։ Դա AI-ով կառուցված հավելվածներում դանդաղ էջերի տարածված պատճառ է։

Ամենօրյա անալոգիա

Պատկերացրեք բրիտանացի ճանապարհորդին և ճապոնացի վաճառողին, որոնք չունեն ընդհանուր լեզու և շփվում են թարգմանչի միջոցով։

Ճանապարհորդը (ձեր հավելվածը) ասում է. «Ես կցանկանայի ձեր երեք ամենաէժան թեյը»։ Թարգմանիչը (ORM-ը) դա ճշգրիտ ճապոներենի (SQL) է վերածում, փոխանցում վաճառողին (տվյալների բազային), իսկ պատասխանը թարգմանում է հետ անգլերենի։

Ճանապարհորդը երբեք չի սովորում ճապոներեն, և շատ զրույցների համար դա լավ է։ Բայց բարդ բանակցության ժամանակ օգտակար է ուղղակի խոսել, և հենց դրա համար ORM-ների մեծ մասը թույլ է տալիս, երբ անհրաժեշտ է, գրել հում SQL։

Ինչպես է աշխատում ORM-ը

Տվյալների բազաները, ինչպիսին Postgres-ն է, տվյալները պահում են աղյուսակների մեջ՝ տողերի և սյուների ձևով, և հարցում են արվում SQL-ով։ Ծրագրավորման լեզուները աշխատում են օբյեկտների հետ՝ ամրագրում՝ date-ով, customer-ով և status-ով։ ORM-ը մեկը մյուսին է քարտեզագրում․

Այս չորս գործողությունները հենց այն CRUD գործողություններն են, որոնց վրա կառուցված է գրեթե յուրաքանչյուր հավելված։

Օրինակ աշխատանքում․ ամրագրումներ Prisma-ով

Հետևյալը սրահի ամրագրման հավելվածի պարզեցված Prisma սխեման է։ Այն նկարագրում է երկու աղյուսակ և դրանց կապը․

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
}

Պարզ խոսքով․ հաճախորդն ունի անուն, յուրահատուկ էլփոստ և բազմաթիվ ամրագրումներ. յուրաքանչյուր ամրագրում ունի սկզբի ժամ և ծառայություն և պատկանում է մեկ հաճախորդի։

Այժմ հավելվածին պետք է. «Լենայի առաջիկա ամրագրումները, սկզբից ամենամոտը»։

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

ORM-ը սա մոտավորապես այսպիսի SQL-ի է վերածում, կատարում է այն և վերադարձնում ամրագրումների օբյեկտների ցուցակ․

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;

$1-ը և $2-ը տեղապահներ են․ էլփոստը և ամսաթիվը ուղարկվում են առանձին՝ հարցման տեքստից դուրս, և հենց դա է կանխում SQL ներարկումը։

Միգրացիաներ

Եթե հետո խնդրեք «թույլ տուր հաճախորդներին ավելացնել հեռախոսահամար», AI-ը Customer մոդելին ավելացնում է phone String? (?-ը նշանակում է կամընտիր) և ստեղծում միգրացիա՝ փոքր SQL սկրիպտ, օրինակ՝ ALTER TABLE "Customer" ADD COLUMN "phone" TEXT;։ Միգրացիաները պահվում են հերթականությամբ, որպեսզի տվյալների բազայի յուրաքանչյուր օրինակ կարելի լինի բերել նույն կառուցվածքին, և փոփոխությունների պատմությունը պահպանվում է։

Տարածված ORM-ներ ըստ լեզվի

ORM-ները տարբեր չափով են թաքցնում SQL-ը։ Prisma-ն օգտագործում է իր սեփական սխեմայի լեզուն և հարցման ոճը, Drizzle-ը միտումնավոր մնում է մոտ SQL-ի կառուցվածքին՝ միաժամանակ ամեն ինչ տիպավորված պահելով։ Հարցումների կառուցիչներ (query builders) կոչվող ավելի թեթև գործիքները, ինչպիսիք են TypeScript-ի Knex-ը կամ Kysely-ն, օգնում են կոդում SQL կառուցել՝ առանց տողերը լրիվ օբյեկտների քարտեզագրելու։

Հիմնական տերմիններ

Տարածված սխալ պատկերացումներ

• «ORM-ը տվյալների բազա է»։ Ոչ։ Այն թարգմանիչ է։ Դեռ անհրաժեշտ է տվյալների բազա, օրինակ՝ Postgres։
• «ORM-ով տվյալները հասկանալու կարիք չկա»։ Վատ նախագծված աղյուսակները ORM-ի միջոցով նույնքան ցավոտ են։ Լավ տվյալների մոդելը ավելի կարևոր է, քան գործիքը։
• «ORM-ները միշտ դանդաղ են»։ Ամենօրյա հարցումները նորմալ են։ Դանդաղությունը սովորաբար գալիս է այնպիսի օրինաչափություններից, ինչպիսիք են N+1 հարցումները կամ բացակայող ինդեքսները, որոնք կարելի է շտկել։
• «ORM նշանակում է, որ SQL ներարկման ռիսկ երբեք չկա»։ Ստանդարտ ORM մեթոդները անվտանգ են, բայց հում SQL-ը, որը գրված է օգտատիրոջ մուտքագրումը ուղղակիորեն միացնելով, դեռ վտանգավոր է։
• «Սխեմայի ֆայլը խմբագրելը փոխում է աշխատող տվյալների բազան»։ Միայն այն դեպքում, երբ միգրացիան ստեղծված և կիրառված է այդ տվյալների բազայի վրա։

Ինչ հարցնել ձեր AI կառուցիչից

• «Ցույց տուր տվյալների բազայի սխեման և բացատրիր յուրաքանչյուր աղյուսակ ու կապ պարզ լեզվով։»
• «Ո՞ր ORM-ն է օգտագործում այս նախագիծը, և որտե՞ղ են միգրացիաները։»
• «Նախքան որևէ աղյուսակ փոխելը ասա, թե արդյոք դա կազդի առկա տվյալների վրա, և երբեք մի ջնջիր տվյալներ պարունակող սյուն առանց հարցնելու։»
• «Ստուգիր ամենադանդաղ էջերը N+1 հարցումների համար և ավելացրու ինդեքսներ այն տեղերում, որտեղ ցուցակները զտվում կամ դասավորվում են։»
• «Համոզվիր, որ օգտատիրոջ մուտքագրում օգտագործող յուրաքանչյուր հարցում անցնում է ORM-ով կամ օգտագործում է պարամետրեր՝ առանց տողային SQL-ի։»

ORM-ները Mythex-ում

Երբ ձեր հավելվածին պետք է տվյալներ պահել, Mythex-ը նախագծին ավելացնում է նվիրված Postgres տվյալների բազա. հարցրեք չաթում կամ օգտագործեք /database հրամանը, և դրա կապի տվյալները ներարկվում են աշխատանքային միջավայր և հրապարակված հավելված (Տվյալների բազա)։ Այնուհետև գործակալը գրում է կոդը, որը կարդում և պահում է ձեր տվյալները։ Եթե ունեք նախընտրություն՝ «օգտագործիր Prisma», «օգտագործիր SQLAlchemy» կամ «պարզ SQL, առանց ORM», ասացեք չաթում։ Երբ ցանկանաք ստուգել կառուցվածքը, խնդրեք գործակալին բացատրել սխեման․ ֆայլերը կարող եք կարդալ կոդի խմբագրիչում։ Ավելի լայն պատկերի համար տե՛ս ինչ է տվյալների բազան և SQL ընդդեմ NoSQL։

Հարցեր