SQL — ORM-нен де ұзақ өмір сүретін келісімшарт

Мен іске қосқан әр өнім кемінде бір фреймворк шешімінен ұзақ өмір сүрді. Дерекқор олардың бәрінен ұзағырақ жасады. Next.js нұсқалары өзгереді, ORM ауысады, команда жаңарады — ал жолдар және схемаға енгізілген жорамалдар қалады. Сондықтан SQL-ді repository класының артындағы іске асыру бөлшегі емес, өнімнің шынайы келісімшарты деп санаймын.

Prisma күнделікті жұмысымның көбін атқарады: типтелген CRUD, репозиторийдегі миграциялар және жаңа маман оқи алатын схема. Бірақ оның жасаған SQL-ін де қараймын. Тізім беті әр жолға жеке сұрау жіберсе, есепке window function керек болса немесе dashboard үш join бойынша GROUP BY қажет етсе, сұрауды $queryRaw арқылы қолмен жазамын не view-ға саламын. Біреу Redis қоспай тұрып EXPLAIN ANALYZE ашамын. «Кэш керек» деген тикеттердің көбінің астарында жетіспейтін индекс жатады.

Шектеулер — алуға болатын ең арзан сапа кепілдігі. NOT NULL, UNIQUE, FOREIGN KEY және CHECK әр жазбада, әр сервистен, тіпті жұма күні қолмен іске қосылған скриптте де орындалады. Zod API-ді қорғайды, ал дерекқор шындықты қорғайды. Ақша бүтін кіші бірліктермен не NUMERIC түрінде сақталады, ешқашан float емес. Төлем webhook-тары екі рет келуі мүмкін, сондықтан idempotency кілті handler-дегі пікірге емес, бірегей индекске сүйенуі керек.

FinTech қателері қатар орындалуда туады. Екі сұрау балансты оқып, екеуі де қаражат жетеді деп шешеді, сосын екеуі де жазады — бұл lost update, оны frontend валидациясы түзете алмайды. Бір атомарлық нұсқауды қалаймын —UPDATE ... SET balance = balance - $1 WHERE id = $2 AND balance >= $1— содан кейін дәл бір жол өзгергенін тексеремін. Не болмаса SELECT ... FOR UPDATE бар транзакция және әр қозғалысты кейін түсіндіруге арналған append-only ledger кестесін қолданамын. $1.5M-нан астам көлем өңдейтін жүйелерде «кейін түсіндіре алу» — жұмыстың мәні.

Индекстер маңызды көрінетін бағандарға емес, шын мәнінде орындалатын сұрауларға сай болуы тиіс. Құрама индексте алдымен теңдік бағандары, соңында диапазон немесе сұрыптау бағаны тұрады; partial index «белсенді» жолдарға пайдалы, ал keyset пагинация OFFSET 50000-нан дұрыс. Тірі кестедегі миграциялар кезеңмен жүреді: nullable баған қосу, топтап толтыру, кейін шектеу қосу; индексті CONCURRENTLY арқылы жасау. Түсте orders кестесін құлыптайтын миграция — қасына pull request тіркелген үзіліс.

Схеманың орнына «икемді» entity-attribute-value кестесін, ешкім модельдегісі келмейтін негізгі бағандарды JSONB-ге жасыруды, unique шектеулерін ойламай барлық жерге soft delete қосуды және EXPLAIN жасалмаған сұраудың алдына кэш қоюды қабылдамаймын. Баяу бетті не күмәнді схеманы жіберсеңіз, сұрау мен жол санын қоса жіберіңіз. Жоспарды, индексті және бірінші қосар шектеуді айтып беремін.