Dasturlash kitobi/6-QISM — Database16 daqiqa

6.14-bob: Migration va seeding strategiyalari

6-QISM — Ma'lumotlar bazasi (Database) · 14-mavzu

1. Kirish va motivatsiya

Uch ORM'ni (Sequelize 6.11, Prisma 6.12, TypeORM 6.13) o'rgandik va har birida migration ni ko'rdik. Endi migration'ning strategiyalarini — ORM-mustaqil, kontseptual darajada — chuqur o'rganamiz: schema'ni vaqt o'tishi bilan xavfsiz boshqarish, production'da nol uzilishsiz (zero-downtime) o'zgartirish, rollback, va seeding (boshlang'ich/test ma'lumot). Bu — real loyihada DB'ni boshqarishning eng amaliy qismi.

Muammo shunday: loyiha o'sadi, talablar o'zgaradi DB schema'si ham o'zgarishi kerak (yangi ustun, yangi jadval, ustun o'zgarishi). Lekin production DB'da real foydalanuvchi ma'lumoti bor — uni qo'lda o'zgartirish (ALTER TABLE) xavfli (xato ma'lumot yo'qoladi, ilova buziladi). Va jamoada — har kim o'z kompyuterida DB'ni bir xil holatda tutishi kerak. Migration — bu muammolarni hal qiladi: schema o'zgarishlarini versiyalangan, qaytariladigan, kod sifatida (git'da) boshqarish.

Production'da eng nozik nuqta — schema o'zgarishi paytida ilova ishlab turishi (zero-downtime). Masalan, "ustunni o'chirish" — agar eski kod hali shu ustunni ishlatayotgan bo'lsa, ilova buziladi. Expand-contract kabi strategiyalar buni hal qiladi. Bu bob: migration falsafasi, zero-downtime naqshlar, rollback, va seeding — chuqur. Real, professional DB boshqaruvi.

O'xshatish: migration — binoni o'zgartirish (remont). Binoda odamlar yashayapti (production — foydalanuvchilar). Devorni buzib qayta qurish (qo'lda ALTER) — odamlarni ko'chirmasdan — xavfli (ustiga tushadi). To'g'ri yo'l — bosqichma-bosqich: yangi devor qur (expand), odamlarni o'tkaz (deploy), eskisini buz (contract) — hech kim zarar ko'rmaydi (zero-downtime). Va har qadam rejalashtirilgan, qaytariladigan (rollback — noto'g'ri bo'lsa, ortga).

Nega muhim?

Schema evolyutsiyasi — loyiha o'sadi, DB o'zgaradi (muqarrar).
Production xavfsizligi — qo'lda ALTER xavfli; migration nazorat ostida.
Jamoa sinxronligi — har kim bir xil schema (git'da).
Zero-downtime — ilova ishlab turib schema o'zgartirish (real talab).

2. Nazariya — chuqur tushuntirish

2.1. Migration nima (takrorlash + chuqur)

Migration — schema o'zgarishini versiyalangan, kod sifatida boshqarish (6.11-6.13):

text

  Migration fayllar (vaqt tartibida — git'da):
  20260101-create-users.js       users jadval yaratish
  20260115-add-phone.js          telefon ustun qo'shish
  20260201-create-orders.js      orders jadval

  Har migration: up (qo'llash) + down (qaytarish)
  DB "qaysi migration'lar qo'llangani"ni eslaydi (migrations jadvali)

Migration — DB'ning git'i: har o'zgarish — versiyalangan fayl (kim, qachon, nima). DB ulardan qaysisini qo'llaganini biladi (migrations jadvali). Yangi muhitda — barcha migration ketma-ket qo'llanadi bir xil schema (3-bob: 2.11 takrori).

2.2. Nega qo'lda ALTER emas (migration)

text

   Qo'lda ALTER TABLE (production DB'da to'g'ridan):
  - Versiya nazorat yo'q (kim/qachon/nima — noma'lum)
  - Jamoa nomuvofiq (sening DB'ng boshqacha)
  - Qaytarib bo'lmaydi (xato  muammo)
  - Test qilinmagan (production'da birinchi marta)

   Migration:
  - Git'da (versiya, kod review — 4, 15)
  - Jamoa/muhitlar sinxron (bir xil migration)
  - Qaytariladigan (down)
  - Test (dev/staging'da avval)

Migration — DB o'zgarishini dasturlash amaliyotiga (git, review, test, CI/CD — 10) keltiradi. Qo'lda ALTER — "production'da jonli operatsiya" (xavfli).

2.3. Migration anatomiyasi (up / down)

text

  Har migration ikki funksiya:
  up()   — o'zgarishni QO'LLASH (jadval yaratish, ustun qo'shish)
  down() — o'zgarishni QAYTARISH (jadval o'chirish, ustun olib tashlash)

  up:   migrate (oldinga)
  down: rollback (ortga — xato bo'lsa)

down (rollback) — har doim yozing (deployhq): migration noto'g'ri bo'lsa, down bilan ortga qaytasiz. down'siz migration — bir tomonlama (xavfli). down — upning aniq teskarisi (qo'shgan ustunni o'chiradi). Test qiling (down ishlaydimi).

2.4. Migration tartibi va holati

text

  Migration FAYL NOMI — vaqt tamg'asi (timestamp) bilan:
  20260101120000-create-users.js    tartibni belgilaydi (xronologik)

  DB'da "migrations" jadvali — qo'llanganlarni eslaydi:
  | name                          | qo'llangan_vaqt |
  | 20260101...create-users       | 2026-01-01      |

  migrate  qo'llanmaganlarni ketma-ket bajaradi
  status   qaysisi qo'llangan/qoldi

Vaqt tamg'asi (timestamp) — migration tartibini belgilaydi (jamoada to'qnashuvni kamaytiradi). DB qo'llangan migration'larni eslaydi — faqat yangilari qo'llanadi. migrate:status — holatni ko'rsatadi.

Migration squash (birlashtirish): loyiha yillar davomida yuzlab migration to'playdi — yangi muhitda hammasini ketma-ket bajarish sekin (va eskilari endi ahamiyatsiz). Squash — allaqachon barcha muhitlarda (production ham) qo'llangan eski migration'larni bitta "boshlang'ich schema" (baseline) migration'ga birlashtirish. Faqat hamma joyda qo'llangan migration'larni birlashtiring (aks holda ba'zi DB ortda qoladi). Bu — tozalik uchun, majburiy emas.

2.5. Migration turlari (o'zgarish xavfliligi)

text

  XAVFSIZ (qo'shimcha — backward-compatible):
   Yangi jadval qo'shish
   Yangi NULLABLE ustun qo'shish
   Yangi indeks (CONCURRENTLY — bloklash kam)

  XAVFLI (buzuvchi — breaking):
   Ustun o'chirish (eski kod ishlatayotgan bo'lsa — buziladi)
   Ustun nomini o'zgartirish (eski kod topolmaydi)
   NOT NULL qo'shish (mavjud NULL qatorlar — xato)
   Tur o'zgartirish (ma'lumot mos kelmasligi)

Asosiy farq: qo'shimcha o'zgarishlar (yangi jadval/ustun) — xavfsiz (eski kod ishlayveradi). Buzuvchi o'zgarishlar (o'chirish/nom/NOT NULL) — ehtiyot (eski kod buziladi). Buzuvchilarni zero-downtime strategiya 2.7-bob bilan.

2.6. Zero-downtime nima va nega

Zero-downtime — ilova ishlab turib schema o'zgartirish (foydalanuvchi sezmaydi — deployhq):

text

  Muammo: deploy paytida
  - Eski kod hali ishlayapti (eski schema kutadi)
  - Yangi kod kelmoqda (yangi schema kutadi)
  - Schema o'zgarmoqda

  Agar schema'ni darrov o'zgartirsang:
   eski kod buziladi (o'chirilgan ustunni so'raydi)
   ilova to'xtaydi (downtime)

  Zero-downtime: bosqichma-bosqich (har bosqichda ikkala kod ham ishlaydi)

Production'da downtime — qabul qilib bo'lmas (foydalanuvchi yo'qotish, pul). Schema o'zgarishi bosqichma-bosqich bo'lishi kerak — har bosqichda eski va yangi kod ikkalasi ham ishlaydi (backward-compatible).

2.7. Expand-Contract naqshi (eng muhim strategiya)

Expand-Contract — zero-downtime'ning asosiy naqshi (deployhq/matthiasbruns):

text

  Misol: "ism" ustunini "to'liq_ism"ga o'zgartirish

  1. EXPAND (kengaytirish):
     yangi ustun "to'liq_ism" QO'SH (eskisi turibdi) — backward-compatible
     migration 1

  2. MIGRATE DATA + DUAL WRITE:
     mavjud ma'lumotni ko'chiring; yangi kod IKKALASIGA ham yozadi (eski + yangi)
     deploy (yangi kod)

  3. CONTRACT (qisqartirish):
     hammasi yangi ustunga o'tgach, eski "ism"ni O'CHIR
     migration 2 (eski kod endi ishlatmaydi)

   Har bosqichda ilova ISHLAYDI (downtime yo'q)

Expand-contract mohiyati (deployhq): avval qo'sh (expand — xavfsiz), keyin o'tkaz (deploy + dual write), oxirida o'chir (contract — eski kod ketgach). Hech qachon "darrov o'zgartirish" — har doim bosqichma-bosqich. Bu — buzuvchi o'zgarishni 2.5-bob xavfsiz qiladi.

2.8. Dual writes (ikkala joyga yozish)

text

  Expand-contract'ning 2-bosqichi (dual write):
  O'tish davrida yangi kod IKKALA ustunga/jadvalga yozadi:
  user.ism = qiymat;          // eski (eski kod o'qiydi)
  user.toliq_ism = qiymat;    // yangi (yangi kod o'qiydi)

   ikkala kod versiyasi ham to'g'ri ma'lumot ko'radi (o'tish xavfsiz)

Dual write (mafiree) — o'tish davrida ikkala joyni yangilash. Eski kod (eski ustun) va yangi kod (yangi ustun) — ikkalasi ham to'g'ri. O'tish tugagach (hamma yangi kodda) — eski ustun o'chiriladi (contract).

2.9. Rollback strategiyasi

text

  Har migration — qaytariladigan (down — 2.3):
   down() ni yozing va TEST qiling (qaytarish ishlaydimi)
   Buzuvchi o'zgarishdan oldin — ma'lumotni ZAXIRA (backup table — 2.10)
   Avtomatik rollback trigger (xato darajasi/latency oshsa — qaytaradi)
   Point-in-time recovery (DB backup — eng oxirgi himoya)

Rollback (deployhq): har migration down bilan qaytariladigan bo'lsin (test qilingan). Buzuvchi o'zgarishda — avtomatik rollback sharti (xato ko'paysa — ortga). Eng oxirgi himoya — DB backup (point-in-time recovery). "Rollback rejasisiz migration — qimor".

2.10. Ma'lumotni zaxiralash (destruktiv o'zgarish)

Ma'lumotni o'chiradigan/o'zgartiradigan migration'dan oldin — zaxira (schemasmith):

text

  Destruktiv migration (ustun/jadval o'chirish, tur o'zgartirish):
  1. Ma'lumotni BACKUP jadvalga ko'chiring (o'chirishdan oldin)
     CREATE TABLE users_backup AS SELECT * FROM users;
  2. Asosiy o'zgarishni qo'llang
  3. Backup'ni saqlash muddati (7/30 kun) — keyin o'chiring

   xato bo'lsa, backup'dan tiklash mumkin

Backup table (schemasmith) — destruktiv o'zgarishdan oldin ma'lumot nusxasi. Migration noto'g'ri bo'lsa (data buzildi) — backup'dan tiklash. Saqlash muddati (retention) belgilanadi. Bu — "down yetmaganda" qo'shimcha himoya.

2.11. Migration validatsiyasi (tekshirish)

text

  Migration'dan keyin tekshiring (mafiree):
   Qator soni mos (oldin/keyin — ma'lumot yo'qolmadi)
   MD5/SHA hash (ma'lumot buzilmadi — ko'chirishda)
   Ilova ishlayapti (smoke test)
   Performance (yangi indeks/schema sekinlashtirmadi)

Migration — "ishladi" deb hisoblashdan oldin tekshiring (mafiree): qator soni, ma'lumot yaxlitligi (hash), ilova holati. Ayniqsa katta/destruktiv migration'da. Avtomatik test (CI — 10) — yaxshi.

2.12. Seeding nima (boshlang'ich ma'lumot)

Seeding — DB'ga boshlang'ich/test ma'lumot solish (6.11: 2.12):

text

  Seed turlari:
  - Boshlang'ich (production): admin foydalanuvchi, kategoriyalar, sozlamalar
    (ilova ishlashi uchun ZARUR ma'lumot)
  - Test/demo (dev): soxta foydalanuvchi, mahsulot (test/ko'rsatish uchun)

  Migration'dan farq: migration — TUZILMA; seed — MA'LUMOT

Seed vs migration: migration — schema (jadval/ustun); seed — ma'lumot (qatorlar). Boshlang'ich seed (admin, kategoriya) — production'da bir marta. Test seed (demo) — dev/test'da (har reset'da).

2.13. Seeding strategiyalari

text

  Idempotent seed (qayta ishga tushsa — dublikat yo'q):
  - "bor bo'lsa o'tkaz, yo'q bo'lsa yarat" (upsert/findOrCreate)
  - har safar yangi yaratmaydi (2.13-JS: idempotentlik)

  Muhit bo'yicha:
  - Production: faqat zaruriy (admin, kategoriya)
  - Dev/test: ko'p soxta ma'lumot (faker bilan generatsiya)

  Tartib: bog'lanish tartibida (avval users, keyin orders — FK)

Seed idempotent bo'lsin (qayta ishga tushsa — dublikat yaratmasin): upsert yoki "bor-yo'qligini tekshir". Aks holda — har seed da admin takrorlanadi. Faker (soxta ma'lumot generatori) — dev/test uchun ko'p ma'lumot.

2.14. CI/CD'da migration (10 ko'prik)

text

  Deploy oqimida migration (10: CI/CD):
  1. Kod build
  2. MIGRATION qo'llash (migrate deploy — 6.12) — DB yangilanadi
  3. Yangi kod deploy

  Tartib MUHIM (expand-contract — 2.7):
  - Qo'shimcha o'zgarish: avval migration, keyin kod
  - Buzuvchi: ehtiyot (bosqichma-bosqich)

  Avtomatik (CI/CD — 10): migrate deploy pipeline'da

Production'da migration CI/CD (10) orqali avtomatik (qo'lda emas). migrate deploy (Prisma) / migration:run (TypeORM) — pipeline'da. Tartib (migration kod) expand-contract bo'yicha. Bu — DevOps (10) bilan bog'lanadi.

2.15. Best practices (14)

text

   Migration har doim (qo'lda ALTER emas — 2.2, 14)
   down (rollback) yozing va test qiling (2.3, 2.9)
   Buzuvchi o'zgarish — expand-contract (zero-downtime — 2.7)
   Destruktiv'dan oldin backup 2.10-bob
   Migration'ni kichik, fokuslangan tuting (bitta o'zgarish)
   Migration'ni git'da, review (4, 15)
   Seed idempotent (dublikat yo'q — 2.13)
   Dev/staging'da avval test (production'da emas)
   Migration'dan keyin validatsiya 2.11-bob; CI/CD (2.14)

3. Strategiyalar — tez ma'lumotnoma

text

  MIGRATION:
  up/down 2.3-bob — qo'llash/qaytarish; vaqt tamg'asi tartibi 2.4-bob
  Xavfsiz: yangi jadval/nullable ustun; Xavfli: o'chirish/NOT NULL/tur 2.5-bob

  ZERO-DOWNTIME (2.6, 2.7):
  Expand  Migrate+Dual write  Contract (bosqichma-bosqich)

  ROLLBACK 2.9-bob: down + backup table 2.10-bob + DB backup

  SEEDING (2.12, 2.13): boshlang'ich/test; idempotent (upsert)

bash

# ORM buyruqlar (6.11-6.13)
npx sequelize-cli db:migrate / db:migrate:undo / db:seed:all
npx prisma migrate dev / migrate deploy
npx typeorm migration:run / migration:revert

4. Batafsil misollar

Misol 1 — Xavfsiz migration (yangi ustun — 2.5)

// Nullable ustun qo'shish (backward-compatible — 2.5)
export async function up(queryInterface, Sequelize) {
  await queryInterface.addColumn("users", "telefon", {
    type: Sequelize.STRING, allowNull: true,           // NULLABLE — eski qatorlar OK (2.5)
  });
}
export async function down(queryInterface) {
  await queryInterface.removeColumn("users", "telefon");   // qaytarish (2.3)
}
// Eski kod telefon'ni bilmaydi, lekin ishlayveradi (qo'shimcha — 2.6)

Misol 2 — Expand-Contract (ustun nomini o'zgartirish — 2.7)

text

  Maqsad: "ism"  "toliq_ism" (xavfsiz, zero-downtime)

  --- Migration 1 (EXPAND) ---
  up: addColumn("users", "toliq_ism", { nullable: true })   // yangi ustun (eski turibdi)

  --- Deploy: yangi kod (dual write — 2.8) ---
  // Yangi kod IKKALASIGA yozadi:
  await user.update({ ism: qiymat, toliq_ism: qiymat });

  --- Ma'lumot ko'chirish (bir martalik) ---
  UPDATE users SET toliq_ism = ism WHERE toliq_ism IS NULL;

  --- Migration 2 (CONTRACT) — hammasi o'tgach ---
  up: removeColumn("users", "ism")                          // eski ustun o'chiring
   endi faqat toliq_ism (eski kod allaqachon yangilangan)

Misol 3 — Xavfli o'zgarishni bosqichlash (NOT NULL — 2.5, 2.7)

text

  Maqsad: "telefon" ustunini NOT NULL qilish (mavjud NULL qatorlar bor)

   Bir qadamda: ALTER COLUMN telefon SET NOT NULL
      mavjud NULL qatorlar BUZADI (xato!)

   Bosqichma-bosqich:
  1. (expand) telefon nullable qo'shilgan (yoki bor)
  2. mavjud NULL'larni to'ldiring: UPDATE users SET telefon = '' WHERE telefon IS NULL
  3. yangi kod telefon'ni majburiy qiladi (validatsiya — 5.9)
  4. (contract) ALTER COLUMN telefon SET NOT NULL (endi NULL yo'q)

Misol 4 — Destruktiv migration + backup (2.10)

sql

-- Ustun o'chirishdan oldin ma'lumotni zaxirala (2.10)
-- Migration up:
CREATE TABLE users_old_data_backup AS                  -- backup (2.10)
SELECT id, eski_ustun FROM users;

ALTER TABLE users DROP COLUMN eski_ustun;              -- keyin o'chiring

-- down (qaytarish — backup'dan):
ALTER TABLE users ADD COLUMN eski_ustun VARCHAR(100);
UPDATE users u SET eski_ustun = b.eski_ustun
  FROM users_old_data_backup b WHERE u.id = b.id;      -- tiklash

Misol 5 — Migration validatsiyasi (2.11)

// Migration'dan keyin tekshirish (2.11)
export async function up(queryInterface) {
  // Oldin: qator soni
  const [oldin] = await queryInterface.sequelize.query("SELECT COUNT(*) FROM users");

  // Ma'lumot ko'chirish (masalan)
  await queryInterface.sequelize.query("UPDATE users SET toliq_ism = ism");

  // Keyin: tekshirish (yo'qolmadi)
  const [keyin] = await queryInterface.sequelize.query(
    "SELECT COUNT(*) FROM users WHERE toliq_ism IS NOT NULL"
  );
  if (oldin[0].count !== keyin[0].count) {
    throw new Error("Ma'lumot ko'chirilmadi to'liq!");   // migration to'xtaydi (2.11)
  }
}

Misol 6 — Idempotent seed (2.13)

// Idempotent seed — qayta ishga tushsa, dublikat yo'q (2.13)
export async function seed() {
  // Admin (bor bo'lsa o'tkaz — upsert)
  await User.findOrCreate({                             // Sequelize (yoki upsert)
    where: { email: "admin@mana.uz" },                 // shu bo'yicha tekshiradi
    defaults: { ism: "Admin", parol: await bcrypt.hash("...", 12), rol: "admin" },
  });

  // Kategoriyalar (zaruriy boshlang'ich — 2.12)
  const kategoriyalar = ["Telefon", "Kompyuter", "Kiyim"];
  for (const nom of kategoriyalar) {
    await Category.findOrCreate({ where: { nom } });    // dublikatsiz
  }
}
// Qayta ishga tushsa — yangi yaratmaydi (bor bo'lsa o'tkazadi — 2.13)

Misol 7 — Test seed (faker bilan — 2.13)

// Dev/test uchun ko'p soxta ma'lumot (faker — 2.13)
import { faker } from "@faker-js/faker";

export async function seedTest() {
  // 100 ta soxta foydalanuvchi (test/demo)
  const users = Array.from({ length: 100 }, () => ({
    ism: faker.person.fullName(),
    email: faker.internet.email(),
    parol: "hashed...",
  }));
  await User.bulkCreate(users);                         // ko'p qator (bulk)

  // Bog'lanish tartibida: avval users, keyin orders (FK — 2.13)
  const allUsers = await User.findAll();
  for (const u of allUsers) {
    await Order.bulkCreate(
      Array.from({ length: faker.number.int({ min: 0, max: 5 }) }, () => ({
        userId: u.id, summa: faker.number.int({ min: 10000, max: 500000 }),
      }))
    );
  }
}

Misol 8 — CI/CD migration (deploy oqimi — 2.14)

yaml

# .github/workflows/deploy.yml (10: CI/CD — soddalashtirilgan)
steps:
  - name: Build
    run: npm run build
  - name: Run migrations                               # MIGRATION (kod'dan oldin — 2.14)
    run: npx prisma migrate deploy                     # production migration
    env:
      DATABASE_URL: ${{ secrets.DATABASE_URL }}        # secrets (14, 5.8)
  - name: Deploy app                                   # keyin yangi kod
    run: npm run deploy
# Tartib: build  migrate  deploy (expand-contract bo'yicha — 2.7, 2.14)

5. To'g'ri va noto'g'ri holatlar

1) Qo'lda ALTER (production)

text

 production DB'da qo'lda ALTER TABLE (versiya yo'q, xavfli — 2.2)
 migration (git, up/down)

2) down (rollback) yozmaslik

//  faqat up (qaytarib bo'lmaydi — 2.3)
export async function up() {...}

//  up + down
export async function up() {...}
export async function down() {...}   // teskarisi

3) Buzuvchi o'zgarishni bir qadamda

text

 ustunni darrov o'chirish (eski kod buziladi — 2.5, 2.6)
 expand-contract (bosqichma-bosqich — 2.7)

4) Destruktiv o'zgarishdan oldin backup yo'q

text

 DROP COLUMN to'g'ridan (xato  ma'lumot yo'q — 2.10)
 avval backup table, keyin o'zgartiring

5) Idempotent bo'lmagan seed

//  har safar yangi admin (dublikat — 2.13)
await User.create({ email: "admin@..." });

//  findOrCreate / upsert
await User.findOrCreate({ where: { email: "admin@..." }, defaults: {...} });

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Migration production'da ilovani buzdi

Sababi: buzuvchi o'zgarish bir qadamda (eski kod buzildi — 2.6). Yechimi: expand-contract; deploy tartibi; rollback (down).

Xato 2 — Migration qaytarib bo'lmaydi

Sababi: down yo'q yoki xato 2.3-bob. Yechimi: down yozing va test qiling; backup 2.10-bob.

Xato 3 — Jamoa DB nomuvofiq

Sababi: kimdir qo'lda o'zgartirgan, migration emas 2.2-bob. Yechimi: faqat migration; migrate:status tekshiring.

Xato 4 — Migration ma'lumotni yo'qotdi

Sababi: destruktiv, backupsiz 2.10-bob. Yechimi: backup table; validatsiya 2.11-bob; DB backup'dan tiklash.

Xato 5 — Seed dublikat yaratdi

Sababi: idempotent emas 2.13-bob. Yechimi: findOrCreate/upsert.

Xato 6 — Seed FK xatosi

Sababi: noto'g'ri tartib (orders avval users'siz — 2.13). Yechimi: bog'lanish tartibida (avval parent).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

ORM'lar (6.11-6.13): har birida migration/seed.
SQL 6.4-bob: ALTER, schema o'zgarishi.
Git (4): migration — versiya nazorat, review.
CI/CD (10): avtomatik migrate deploy.
Tranzaksiya 6.9-bob: migration atomik.
Validatsiya 5.9-bob: o'tish davrida kod.
Backup 2.20-bob: destruktiv himoya.
Idempotentlik 5.22-bob: seed.
DevOps (10): zero-downtime deploy.

8. Eng yaxshi amaliyotlar (best practices)

Migration har doim (qo'lda ALTER emas — 2.2, 14).
down (rollback) yozing va test qiling (2.3, 2.9).
Buzuvchi o'zgarish — expand-contract (zero-downtime — 2.7); dual write 2.8-bob.
Destruktiv'dan oldin backup (table + DB — 2.10).
Migration kichik, fokuslangan (bitta o'zgarish — 2.15).
Git'da, review (4, 15); dev/staging'da test 2.15-bob.
Migration'dan keyin validatsiya (qator/hash — 2.11).
Seed idempotent (findOrCreate/upsert — 2.13).
Seed tartibi (bog'lanish — avval parent — 2.13).
CI/CD'da avtomatik (migrate deploy — 2.14, 10).

9. Amaliy loyiha: "Migration va Seeding Tizimi"

Migration/seeding strategiyalarini mustahkamlash.

Maqsad

ORM (Sequelize/Prisma/TypeORM) bilan migration va seeding tizimini qurish: xavfsiz schema o'zgarishi, expand-contract, rollback, idempotent seed.

Talablar (requirements)

Boshlang'ich migration: jadvallar (up/down — Misol 1).
Xavfsiz o'zgarish: nullable ustun qo'shish (backward-compatible — 2.5).
Expand-contract: ustun nomini o'zgartirish (3 bosqich — Misol 2, 2.7).
Buzuvchini bosqichlash: NOT NULL qo'shish (Misol 3, 2.5).
Destruktiv + backup: ustun o'chirish (backup table — Misol 4, 2.10).
Migration validatsiyasi: qator soni tekshirish (Misol 5, 2.11).
Idempotent seed: admin/kategoriya (findOrCreate — Misol 6, 2.13).
Test seed: faker bilan ko'p ma'lumot; FK tartibi (Misol 7, 2.13).
CI/CD: deploy oqimida migration (Misol 8, 2.14).
Rollback test: down ishlashini ko'rsating 2.9-bob.

Maslahatlar (hint)

down har doim (2.3, 2-xato).
Buzuvchi expand-contract (2.7, 3-xato).
Destruktiv backup table (2.10, 4-xato).
Seed findOrCreate (idempotent — 2.13, 5-xato).
Seed tartibi avval parent (FK — 2.13, 6-xato).
CI/CD migrate kod'dan oldin 2.14-bob.

"Tayyor" mezonlari (acceptance criteria)

Migration (up/down) ishlaydi.
Xavfsiz o'zgarish (nullable).
Expand-contract (3 bosqich) ko'rsatilgan.
Buzuvchi o'zgarish bosqichlangan.
Destruktiv + backup.
Migration validatsiyasi.
Idempotent seed (dublikat yo'q).
Test seed (faker, FK tartibi).
CI/CD migration.
Rollback (down) ishlaydi.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda DB boshqaruvining amaliy qismini — migration va seeding strategiyalari — chuqur o'rgandik:

Migration (versiyalangan schema — git'da — 2.1); nega qo'lda ALTER emas 2.2-bob; up/down 2.3-bob; tartib/holat 2.4-bob; xavfsiz vs buzuvchi 2.5-bob.
Zero-downtime (ilova ishlab turib — 2.6); expand-contract (qo'sho'tkazo'chir — 2.7); dual write 2.8-bob.
Rollback (down + backup table + DB backup — 2.9, 2.10); validatsiya 2.11-bob.
Seeding (boshlang'ich/test — 2.12); idempotent (findOrCreate — 2.13); faker; CI/CD 2.14-bob.

Keyingi bob — 6.15-bob: Connection pooling va ER modeling (DB dizayni). 6-QISMning yakuniy bobi. Connection pooling (ulanishlarni samarali boshqarish — chuqur) va ER modeling (Entity-Relationship — DB'ni boshidan to'g'ri loyihalash: entity, atribut, bog'lanish, diagramma). Bu — butun 6-QISMni umumlashtiradi (dizayndan optimizatsiyagacha).

Foydalanilgan rasmiy/ishonchli manbalar

DeployHQ — Database Migration Strategies for Zero-Downtime; Matthias Bruns — production migrations
Mafiree / SchemaSmith — zero-downtime patterns (expand-contract, dual write, backup)
DEV (2026) — Database Migrations in Production; ORM migration docs (Sequelize/Prisma/TypeORM)

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!