SQL — ORM’dan ham uzoq yashaydigan shartnoma

Men chiqargan har bir mahsulot kamida bitta framework qaroridan uzoq yashadi. Ma’lumotlar bazasi esa ularning barchasidan uzoq yashadi. Next.js versiyalari o‘zgaradi, ORM almashtiriladi, jamoa yangilanadi; qatorlar va sxemaga singdirilgan taxminlar qoladi. Shu sababli SQL’ni repository klassi ortidagi implementatsiya tafsiloti emas, mahsulotning haqiqiy shartnomasi deb bilaman.

Prisma kundalik ishlarimning katta qismini qoplaydi: tiplangan CRUD, repozitoriydagi migratsiyalar va yangi xodim o‘qiy oladigan sxema. Lekin u yaratgan SQL’ni ham o‘qiyman. Ro‘yxat sahifasi har qator uchun bittadan so‘rov yuborsa, hisobotga window function kerak bo‘lsa yoki dashboard uchta join bo‘yicha GROUP BY talab qilsa, so‘rovni $queryRaw bilan qo‘lda yozaman yoki view’ga joylayman. Kimdir Redis qo‘shishidan oldin EXPLAIN ANALYZE’ni ochaman. “Kesh kerak” degan ticketlarning ko‘pida yetishmayotgan indeks bo‘ladi.

Cheklovlar — topish mumkin bo‘lgan eng arzon QA. NOT NULL, UNIQUE, FOREIGN KEY va CHECK har bir yozuvda, har bir servisdа, hatto juma kuni qo‘lda ishga tushirilgan skriptda ham ishlaydi. Zod API’ni, ma’lumotlar bazasi esa haqiqatni himoya qiladi. Pul butun kichik birliklarda yoki NUMERIC ko‘rinishida saqlanadi, hech qachon float’da emas. To‘lov webhook’i ikki marta kelishi mumkin, shu bois idempotency kaliti handler’dagi izohga emas, yagona indeksga tayanishi kerak.

FinTech xatolari concurrency’da yashaydi. Ikki so‘rov balansni o‘qib, ikkalasi ham mablag‘ yetadi deb qaror qiladi va ikkalasi ham yozadi — bu lost update, uni frontend validatsiyasi tuzata olmaydi. Bitta atomar buyruqni ma’qul ko‘raman —UPDATE ... SET balance = balance - $1 WHERE id = $2 AND balance >= $1— so‘ng aynan bitta qator o‘zgarganini tekshiraman. Yoki SELECT ... FOR UPDATE’li transaction va har bir harakatni keyin izohlash uchun append-only ledger jadvalidan foydalanaman. $1,5 mln.dan ortiq tranzaksiya hajmiga ega tizimlarda “keyin izohlash” ishning o‘zidir.

Indekslar muhim ko‘rinadigan ustunlarga emas, amalda bajariladigan so‘rovlarga mos bo‘lishi kerak. Birlashma indeksida avval tenglik ustunlari, oxirida diapazon yoki tartiblash ustuni turadi; partial index “faol” qatorlar uchun, keyset pagination esa OFFSET 50000’dan afzal. Ishlab turgan jadvaldagi migratsiya bosqichma-bosqich qilinadi: nullable ustun qo‘shish, guruhlab to‘ldirish, keyin cheklovni kiritish; indeksni CONCURRENTLY bilan yaratish. Tush payti orders jadvalini qulflaydigan migratsiya — yoniga pull request ilova qilingan uzilish.

Sxema o‘rniga “moslashuvchan” entity-attribute-value jadvalini, hech kim modellashni istamaydigan muhim maydonlarni JSONB’da yashirishni, unique cheklovlarini hisobga olmay hamma joyga soft delete qo‘shishni va EXPLAIN qilinmagan so‘rov oldiga kesh qo‘yishni rad etaman. Sekin sahifa yoki shubhali sxemani yuborsangiz, so‘rov va qatorlar sonini ham qo‘shing. Reja, indeks va birinchi qo‘shadigan cheklovimni aytaman.