WisarWisar
Dasturlash kitobi/6-QISM — Database20 daqiqa

6.1-bob: Ma'lumotlar bazasi asoslari — SQL vs NoSQL

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

1. Kirish va motivatsiya

5-QISMda backend qurdik va ko'p marta "DB'ga saqlaymiz", "DB'dan olamiz" deb o'tdik (foydalanuvchi, buyurtma, mahsulot). Endi backend'ning yuragiga — ma'lumotlar bazasi (database) ga — yetib keldik. Har bir real ilova ma'lumotni biror joyda doimiy saqlashi kerak: foydalanuvchilar, postlar, buyurtmalar, to'lovlar. Bu ma'lumotni qayerda, qanday saqlash — ilovaning eng muhim qarori. Noto'g'ri tanlov — keyinroq qayta yozish (juda qimmat).

Bu qism — backend dasturchining ikkinchi ustuni (birinchisi — server/API, 5-QISM). DB'ni bilmasdan backend dasturchi bo'lib bo'lmaydi. Va bu bob — butun qismning poydevori: bu yerda biz "qaysi DB'ni tanlash" degan asosiy savolga javob beramiz. Ikki katta dunyo bor: SQL (relatsion — jadval) va NoSQL (asosan hujjat — MongoDB). Ularning farqi, kuchli/zaif tomonlari, va qachon qaysi biri — shu bobda.

Bu bob ko'proq tushunchaviy (nazariy) — chunki to'g'ri tanlov uchun "qanday ishlaydi" dan ham muhimrog'i "nega bunday, qachon qaysi biri" ni tushunish kerak. Keyingi boblarda amaliyot (MongoDB, SQL, ORM) — lekin avval poydevor.

O'xshatish 1 (DB nima): ma'lumotlar bazasi — ulkan, tartibli kutubxona. Faylga yozish — kitoblarni xonaga uyub tashlash (topish qiyin, tartibsiz). DB — javonlar, kataloglar, indeks bilan kutubxona: istalgan kitobni tez topasiz, qo'shasiz, o'zgartirasiz, bir vaqtda ko'p kishi ishlatadi, yo'qolmaydi.

O'xshatish 2 (SQL vs NoSQL): SQL — Excel jadvali (qat'iy ustunlar, har qator bir xil shaklda, jadvallar bir-biriga bog'langan). NoSQL (hujjat) — papkadagi hujjatlar (har hujjat o'z shaklida, moslashuvchan, hammasi bir joyda). Excel — tartib va aniqlik; papka — erkinlik va tezlik. Ikkalasining ham o'rni bor.

Nega muhim?

  • Backend yuragi — har ilova ma'lumotni DB'da saqlaydi.
  • Eng muhim qaror — DB tanlovi; noto'g'ri tanlov qimmat.
  • Poydevor — keyingi boblar (MongoDB, SQL, ORM) shu tushunchaga quriladi.
  • Stack talabi — sizning stack'ingda MongoDB ham, SQL (PostgreSQL/MySQL) ham bor.

2. Nazariya — chuqur tushuntirish

2.1. Nega ma'lumotlar bazasi (fayl yetarli emas)

Ma'lumotni oddiy faylga (5.3: JSON fayl) saqlash mumkin. Lekin real ilovada bu yetmaydi:

text
  Faylga saqlash muammolari:
   Qidirish sekin — millionlab yozuv ichidan birni topish (butun faylni o'qish)
   Bir vaqtda yozish — ikki foydalanuvchi bir paytda yozsa, ma'lumot buziladi
   Bog'lanish yo'q — foydalanuvchi va uning buyurtmalarini bog'lash qiyin
   Yaxlitlik yo'q — yarim yozilib qolsa, ma'lumot buzuq
   Xavfsizlik, zaxira, masshtab — hammasi qo'lda

  DB bularning HAMMASINI hal qiladi (qidirish, parallel, bog'lanish, yaxlitlik)

DBMS (Database Management System) — ma'lumotlar bazasini boshqaruvchi dastur (MongoDB, PostgreSQL, MySQL). U qidiruv (indeks), parallel kirish (tranzaksiya/lock), yaxlitlik, zaxira, xavfsizlikni ta'minlaydi. Siz DBMS bilan "gaplashasiz" (so'rov), u ma'lumotni boshqaradi.

2.2. Doimiylik (persistence) — RAM vs disk (0.1)

DB ma'lumotni doimiy (persistent) saqlaydi — ilova/server o'chsa ham, qoladi:

text
  RAM (xotira — 0.1):  tez, lekin O'CHSA YO'QOLADI (vaqtinchalik — Redis qisman)
  Disk 0.2-bob:          sekinroq, lekin DOIMIY (o'chsa ham qoladi)

  DB ma'lumotni DISKDA saqlaydi (doimiy) + RAM'da keshlaydi (tez — ichki optimallashtirish)

Eslab qoling (0.1, 5.21): Redis — asosan RAM (tez, vaqtinchalik); MongoDB/PostgreSQL — disk (doimiy). DB — ilovaning "uzoq muddatli xotirasi".

2.3. Ikki katta dunyo: SQL va NoSQL

Ma'lumotlar bazalari ikki katta oilaga bo'linadi (ibm):

text
  SQL (Relatsion):                 NoSQL ("Not Only SQL"):
  - Jadval (table) — ustun/qator    - Turli modellar (hujjat, kalit-qiymat, ...)
  - Qat'iy schema                   - Moslashuvchan schema
  - Jadvallar bog'langan (relations) - Denormalizatsiya (birga saqlash)
  - SQL tili                        - Har xil API
  - PostgreSQL, MySQL, ...          - MongoDB, Redis, Cassandra, ...
  - ACID (kuchli yaxlitlik)          - BASE (mavjudlik, masshtab)

"NoSQL" — "SQL emas" emas, balki "Not Only SQL" (faqat SQL emas) — relatsion bo'lmagan turli DB'lar to'plami. Keyingi bo'limlarda har birini chuqur ko'ramiz.

2.4. Relatsion model (SQL) — jadval, qator, ustun

Relatsion DB — ma'lumotni jadvallar (table) da saqlaydi; jadval — ustunlar (columns) va qatorlar (rows) dan iborat (Excel kabi):

text
  users jadvali:
  ┌─────┬──────────┬───────────┬───────┐
  │ id  │ ism      │ email     │ yosh  │    ustunlar (columns) — maydonlar
  ├─────┼──────────┼───────────┼───────┤
  │ 1   │ Ali      │ ali@a.uz  │ 25    │    qator (row) — bitta yozuv
  │ 2   │ Vali     │ vali@a.uz │ 30    │
  └─────┴──────────┴───────────┴───────┘
        Primary Key (PK) — har qatorning noyob identifikatori

Asosiy tushunchalar: Jadval (table) — bir turdagi ma'lumotlar (users, products); qator (row/record) — bitta yozuv (bitta foydalanuvchi); ustun (column/field) — maydon (ism, email); Primary Key — qatorni noyob aniqlovchi (id).

2.5. Bog'lanishlar (relations) — SQL'ning kuchi

Relatsion DB'ning eng muhim xususiyati: jadvallarni bir-biriga bog'lash (relations). Masalan, foydalanuvchi va uning buyurtmalari:

text
  users jadvali:              orders jadvali:
  ┌────┬───────┐              ┌────┬─────────┬──────────┐
  │ id │ ism   │              │ id │ user_id │ summa    │
  ├────┼───────┤              ├────┼─────────┼──────────┤
  │ 1  │ Ali   │◀────────────│ 10 │ 1       │ 50000    │  user_id=1  Ali
  │ 2  │ Vali  │◀──┐         │ 11 │ 1       │ 30000    │  (Ali'ning 2 buyurtmasi)
  └────┴───────┘   └─────────│ 12 │ 2       │ 80000    │  user_id=2  Vali
                             └────┴─────────┴──────────┘
            Foreign Key (FK) — boshqa jadvalga ishora (user_id  users.id)

Foreign Key (FK) — bir jadvaldan boshqasiga ishora (orders.user_id users.id). Bu — bog'lanishning asosi. Ma'lumot takrorlanmaydi (Ali'ning ismi faqat users'da; orders'da faqat user_id). So'rovda JOIN 6.7-bob bilan birlashtiriladi.

2.6. SQL tili (Structured Query Language)

SQL — relatsion DB bilan ishlash tili (so'rov yozish). Standart, deklarativ (nima kerakligini aytasiz, qanday — DB hal qiladi):

sql
SELECT ism, email FROM users WHERE yosh > 18;   -- 18 dan katta foydalanuvchilar
INSERT INTO users (ism, email) VALUES ('Ali', 'ali@a.uz');   -- qo'shish
UPDATE users SET yosh = 26 WHERE id = 1;        -- yangilash
DELETE FROM users WHERE id = 2;                 -- o'chirish

SQL — barcha relatsion DB'da (PostgreSQL, MySQL — 6.5, 6.6) deyarli bir xil (standart). Bir marta o'rgansangiz — hammasida ishlaydi. 6.4-bobdan boshlab chuqur o'rganamiz.

2.7. NoSQL turlari — to'rt xil (chuqur)

NoSQL — bitta narsa emas, to'rt xil model (designgurus/tech-insider):

text
  1. DOCUMENT (hujjat) — MongoDB, Couchbase
     Ma'lumot — JSON-ga o'xshash hujjat (moslashuvchan)
     { _id: 1, ism: "Ali", manzil: { shahar: "Toshkent" }, teglar: ["vip"] }

  2. KEY-VALUE (kalit-qiymat) — Redis 5.21-bob, DynamoDB
     Oddiy kalit  qiymat (eng tez, eng oddiy)
     "user:1"  "{...}"

  3. WIDE-COLUMN (ustunli) — Cassandra, HBase
     Ulkan, taqsimlangan jadvallar (juda katta ma'lumot)

  4. GRAPH (graf) — Neo4j (3.7: graf)
     Tugun va bog'lanishlar (ijtimoiy tarmoq, tavsiya)
     (Ali)─[do'st](Vali)─[do'st](Hasan)

Eng keng tarqalgani — Document (MongoDB). Sizning stack'ingda u bor (Mongoose — 6.2). Key-value (Redis) — 5.21'da ko'rdik (kesh). Graph va wide-column — maxsus holatlar. Bu qismda asosan document (MongoDB) ni o'rganamiz.

2.8. Document DB (MongoDB) — chuqur

MongoDB — eng mashhur document DB. Ma'lumot collection (jadval kabi) ichida document (hujjat — JSON kabi) sifatida saqlanadi:

text
  SQL atamasi        MongoDB atamasi
  ─────────────────────────────────────
  Database           Database
  Table (jadval)     Collection (to'plam)
  Row (qator)        Document (hujjat)
  Column (ustun)     Field (maydon)
  Primary Key (id)   _id (avtomatik)

  users collection:
  {
    _id: ObjectId("..."),
    ism: "Ali",
    manzil: { shahar: "Toshkent", tuman: "Yunusobod" },    ichma-ich (nested)
    teglar: ["vip", "faol"],                                 massiv
    buyurtmalar: [{ summa: 50000 }, { summa: 30000 }]        birga saqlash (embed)
  }

Document'ning kuchi: bitta hujjatda ichma-ich ma'lumot (manzil, massiv, hatto buyurtmalar) saqlanadi — JavaScript obyektiga o'xshaydi (2.8-JS). JOIN'siz, bitta o'qishda hammasi keladi (tez). Bu — SQL'dan asosiy farq.

2.9. Schema: qat'iy (SQL) vs moslashuvchan (NoSQL)

Schema — ma'lumotning shakli/tuzilishi (qaysi maydonlar, qaysi turlar):

text
  SQL — QAT'IY schema (schema-on-write):
  Avval jadval tuzasiz (ustunlar, turlar belgilanadi)  keyin ma'lumot
  Har qator BIR XIL shaklda bo'lishi SHART (ism: text, yosh: int)
  Yangi ustun  butun jadvalni o'zgartirish (migration — 6.16)

  NoSQL — MOSLASHUVCHAN schema (schema-on-read):
  Schema oldindan shart emas; har hujjat HAR XIL shaklda bo'lishi mumkin
  { ism: "Ali" } va { ism: "Vali", yosh: 30, vip: true } — bir collection'da
  Yangi maydon  shunchaki qo'shasiz (o'zgartirishsiz)

Trade-off: SQL qat'iyligi — aniqlik va yaxlitlik (noto'g'ri shakl kira olmaydi); NoSQL moslashuvchanligi — tezkor rivojlanish (schema o'zgarishi oson), lekin intizom kerak (har xil shakl chalkashlik keltirishi mumkin). Mongoose 6.2-bob NoSQL'ga schema "qo'shadi" (ikkalasi balansi).

2.10. Normalizatsiya vs denormalizatsiya (kirish)

Ma'lumotni qanday tashkil qilish — ikki falsafa:

text
  NORMALIZATSIYA (SQL falsafasi — 6.10):
  Ma'lumotni BO'LIB, takrorlamaslik. Bog'lanish (FK) bilan ulash.
  users (ism) + orders (user_id) — Ali ismi FAQAT bir joyda
   Takror yo'q, izchil;  JOIN kerak (birlashtirish)

  DENORMALIZATSIYA (NoSQL ko'p ishlatadi):
  Bog'liq ma'lumotni BIRGA saqlash (takror bo'lsa ham).
  user document ichida buyurtmalar ham (embed — 2.8)
   Bir o'qishda hammasi (tez);  takror, yangilashda ko'p joyni o'zgartirish

Asosiy farq: SQL — "bir marta sakla, bog'la" (normalizatsiya); NoSQL — "birga sakla, tez o'qi" (denormalizatsiya). Bu — ikki dunyoning falsafiy farqi. 6.3 (MongoDB relations) va 6.10 (normalizatsiya) da chuqur.

2.11. ACID — SQL'ning kafolati (yaxlitlik)

ACID — relatsion DB'ning tranzaksiya kafolati (yaxlitlik — phoenixnap):

text
  A — Atomicity (atomiklik): tranzaksiya — HAMMASI yoki HECH NARSA
      (pul o'tkazish: hisobdan yechish + qo'shish — ikkalasi yoki hech biri)
  C — Consistency (izchillik): ma'lumot doim to'g'ri holatda (qoidalar buzilmaydi)
  I — Isolation (izolyatsiya): parallel tranzaksiyalar bir-biriga xalaqit bermaydi
  D — Durability (doimiylik): tasdiqlangan ma'lumot yo'qolmaydi (o'chsa ham)

Nega muhim: bank, to'lov, buyurtma — zaruriy (xato bo'lmasligi shart — 5.16: idempotentlik bilan bog'liq). Misol: pul o'tkazishda "hisobdan yechildi, lekin qo'shilmadi" — falokat. ACID buni oldini oladi (atomiklik — ikkalasi yoki hech biri). SQL — ACID'ning ustasi. (Zamonaviy MongoDB ham tranzaksiya qo'llaydi, lekin SQL — kuchliroq.)

2.12. BASE — NoSQL falsafasi (mavjudlik, masshtab)

BASE — ko'p NoSQL DB'ning yondashuvi (ACID'ning muqobili — aws):

text
  BA — Basically Available (asosan mavjud): tizim doim javob beradi (xato bo'lsa ham)
  S  — Soft state (yumshoq holat): holat vaqt bilan o'zgarishi mumkin
  E  — Eventual consistency (oxir-oqibat izchillik):
       ma'lumot DARROV emas, BIROZDAN keyin hamma joyda bir xil bo'ladi

Eventual consistency — kalit tushuncha: katta, taqsimlangan tizimda (ko'p server) ma'lumot darrov hamma serverga yetmaydi — biroz kechikadi, lekin oxir-oqibat izchil bo'ladi. Masalan, like soni bir necha sekund kechikishi mumkin (mayli). Bank uchun — yaroqsiz (ACID kerak); ijtimoiy tarmoq uchun — yaxshi (tezlik/mavjudlik muhimroq).

2.13. CAP teoremasi (taqsimlangan DB tanlov)

CAP teoremasi — taqsimlangan DB'da (ko'p server) bir vaqtda faqat ikkitasini kafolatlash mumkin (medium/abstractalgorithms):

text
  C — Consistency (izchillik): har o'qish eng so'nggi yozuvni qaytaradi
  A — Availability (mavjudlik): har so'rov javob oladi
  P — Partition tolerance (bo'linishga chidamlilik): serverlar orasida aloqa
      uzilsa ham ishlaydi

  Tarmoq bo'linishi (P) MUQARRAR (serverlar orasida aloqa uziladi) 
  shuning uchun C yoki A dan birini TANLASH kerak:

  CP (Consistency + Partition) — SQL, MongoDB: izchillik muhim (bank)
  AP (Availability + Partition) — Cassandra, DynamoDB: mavjudlik muhim (ijtimoiy)

Sodda ma'no: tarmoq uzilganda (P — muqarrar), DB ikki yo'ldan birini tanlaydi: izchil bo'lish (lekin balki javob bermaslik — CP) yoki javob berish (lekin balki eski ma'lumot — AP). Bank — CP (to'g'rilik muhim); ijtimoiy tarmoq — AP (har doim ishlashi muhim). Bu — chuqur tushuncha (9.10: distributed systems).

2.14. Masshtablash: vertikal vs gorizontal

DB'ni katta yukka moslash (scaling) — ikki yo'l:

text
  VERTIKAL (scale up) — bitta serverni KUCHAYTIRISH (ko'proq CPU/RAM/disk)
  ┌──────┐      ┌──────────┐
  │ kichik│    │  KATTA   │   (bitta, lekin kuchli server)
  └──────┘      └──────────┘
   Sodda;  chegara bor (eng kuchli server ham cheklangan), qimmat
   SQL odatda shunday (gorizontal qiyinroq)

  GORIZONTAL (scale out) — KO'P serverga bo'lish (sharding — 6.3)
  ┌────┐ ┌────┐ ┌────┐ ┌────┐
  │ s1 │ │ s2 │ │ s3 │ │ s4 │   (ko'p oddiy server, ma'lumot bo'lingan)
  └────┘ └────┘ └────┘ └────┘
   Deyarli cheksiz;  murakkab (ma'lumot bo'linadi)
   NoSQL odatda shunday (yaratilishidan masshtab uchun)

Asosiy farq: SQL — vertikal (kuchli bitta server; gorizontal qiyin — JOIN/ACID sababli). NoSQL — gorizontal (ko'p serverga oson bo'linadi — denormalizatsiya/BASE sababli). Bu — "katta ma'lumot" (big data) uchun NoSQL'ning afzalligi.

2.15. SQL'ning kuchli va zaif tomonlari

text
   SQL KUCHLI:
  - Murakkab bog'lanish (JOIN — 6.7), murakkab so'rovlar
  - ACID (yaxlitlik — bank, to'lov — 2.11)
  - Aniq schema (ma'lumot izchilligi)
  - Standart til, yetuk ekotizim
  - Takrorlanmas ma'lumot (normalizatsiya)

   SQL ZAIF:
  - Gorizontal masshtab qiyin 2.14-bob
  - Qat'iy schema (o'zgartirish — migration)
  - Juda katta yuk/ma'lumotda murakkab

2.16. NoSQL (document) ning kuchli va zaif tomonlari

text
   NoSQL (MongoDB) KUCHLI:
  - Moslashuvchan schema (tezkor rivojlanish — 2.9)
  - Gorizontal masshtab (katta ma'lumot — 2.14)
  - Tez o'qish (denormalizatsiya, JOIN'siz — 2.10)
  - JS bilan tabiiy (JSON-ga o'xshash document — 2.8)

   NoSQL ZAIF:
  - Murakkab bog'lanish qiyinroq (JOIN yo'q/cheklangan)
  - Yaxlitlik kuchsizroq (BASE — 2.12); takror ma'lumot
  - Intizom kerak (schema erkinligi chalkashlik keltirishi mumkin)

2.17. Qachon SQL, qachon NoSQL (eng muhim qaror)

text
  SQL TANLA (PostgreSQL/MySQL — 6.5, 6.6):
   Murakkab bog'lanishlar (ko'p jadval, JOIN) — e-commerce, ERP, bank
   Yaxlitlik muhim (to'lov, moliya, buyurtma) — ACID
   Murakkab hisobot/analitika so'rovlari
   Schema barqaror, aniq

  NoSQL TANLA (MongoDB — 6.2):
   Moslashuvchan/o'zgaruvchan ma'lumot (har xil shakl)
   Juda katta ma'lumot, yuqori masshtab (big data, IoT, loglar)
   Tezkor rivojlanish (MVP, startap — schema tez o'zgaradi)
   Hujjatga tabiiy ma'lumot (profil, katalog, kontent)

Haqiqat: ko'p loyiha ikkalasini ham ishlatadi 2.18-bob. Boshlovchi uchun — MongoDB tez (JS bilan tabiiy); jiddiy bog'lanish/yaxlitlik — PostgreSQL. Ikkalasini ham o'rgan (sizning stack'ingda ikkalasi bor). "Eng yaxshi DB" yo'q — vazifaga mos DB bor.

2.18. Polyglot persistence (ko'p DB birga)

Real, katta ilova ko'pincha bir nechta DB'ni birga ishlatadi (har vazifaga mos):

text
  Bitta e-commerce ilova:
  PostgreSQL   buyurtma, to'lov (ACID, bog'lanish — 2.11)
  MongoDB      mahsulot katalogi (moslashuvchan — 2.9)
  Redis        kesh, sessiya (tez — 5.21)
  Elasticsearch  qidiruv (matn bo'yicha)

  Har DB — o'z kuchli sohasida (polyglot persistence)

Bu — "bitta DB hamma narsani qiladi" emas, balki "har vazifaga mos DB". Murakkab, lekin kuchli. Boshlovchi bitta DB'dan boshlaydi; o'sgan sari ko'payadi.

2.19. Backend'da DB qanday ulanadi (stack — 5-QISM bilan)

text
  Node.js ilova (5-QISM) ──driver/ORM──▶ DB (MongoDB/PostgreSQL)

  Ulanish usullari:
  - Driver (to'g'ridan): mongodb, pg (past daraja)
  - ODM/ORM (qulay): Mongoose (MongoDB — 6.2), Sequelize/Prisma/TypeORM (SQL — 6.14)

  Connection pool 6.17-bob — ulanishlarni qayta ishlatish (tez)

ORM/ODM 6.14-bob — DB bilan ishlashni osonlashtiruvchi qatlam (SQL/so'rov yozmasdan, JS obyektlari bilan). Mongoose (MongoDB uchun ODM), Prisma/Sequelize/TypeORM (SQL uchun ORM). Keyingi boblarda chuqur.

2.20. Xavfsizlik va best practices (14)

text
   DB kirish ma'lumotlari (parol) .env'da (5.8, 14); kodga yozma
   SQL injection himoyasi (parametrli so'rov — 6.4, 14); NoSQL injection 6.2-bob
   Eng kam imtiyoz (DB foydalanuvchisiga faqat zarur ruxsat — 14)
   Zaxira (backup) — muntazam; ma'lumot yo'qolmasin
   Connection pool (ulanishni qayta ishlatish — 6.17)
   Indeks (qidiruv tezligi — 6.3); maxfiy ma'lumot shifrlash (14)
   Production DB to'g'ridan internetga ochiq qoldirma (14)

3. Sintaksis / asosiy taqqoslash — tez ma'lumotnoma

text
  ┌──────────────┬─────────────────────┬──────────────────────┐
  │              │ SQL (PostgreSQL)    │ NoSQL (MongoDB)      │
  ├──────────────┼─────────────────────┼──────────────────────┤
  │ Tuzilma      │ jadval/qator/ustun  │ collection/document  │
  │ Schema       │ qat'iy              │ moslashuvchan        │
  │ Bog'lanish   │ JOIN (FK)           │ embed/reference      │
  │ Til          │ SQL                 │ MongoDB query/API    │
  │ Yaxlitlik    │ ACID (kuchli)       │ BASE (moslashuvchan) │
  │ Masshtab     │ vertikal            │ gorizontal           │
  │ Node.js      │ pg/Prisma/Sequelize │ Mongoose             │
  │ Qachon       │ bog'lanish/yaxlitlik│ moslashuvchanlik/masshtab│
  └──────────────┴─────────────────────┴──────────────────────┘
sql
-- SQL (relatsion)
SELECT * FROM users WHERE yosh > 18;
js
// MongoDB (document)
db.users.find({ yosh: { $gt: 18 } });

4. Batafsil misollar (bir ma'lumot — ikki yondashuv)

Misol 1 — Bir xil ma'lumot: SQL vs MongoDB (2.4, 2.8)

text
  Vazifa: foydalanuvchi va uning manzili.

  SQL (ikki jadval — normalizatsiya — 2.10):
  users:      | id | ism  |          addresses: | id | user_id | shahar    |
              | 1  | Ali  |                     | 1  | 1       | Toshkent  |
   bog'lash: JOIN 6.7-bob

  MongoDB (bitta hujjat — denormalizatsiya — 2.10):
  {
    _id: 1, ism: "Ali",
    manzil: { shahar: "Toshkent", tuman: "Yunusobod" }    birga (embed)
  }
   bir o'qishda hammasi (JOIN'siz)

Misol 2 — One-to-Many (foydalanuvchi buyurtmalar — 2.5, 2.10)

text
  SQL (FK bilan — 2.5):
  users:  | id | ism |       orders: | id | user_id | summa |
          | 1  | Ali |               | 10 | 1       | 50000 |
                                      | 11 | 1       | 30000 |
  So'rov: SELECT * FROM orders WHERE user_id = 1;  (Ali'ning buyurtmalari)

  MongoDB — ikki variant:
  a) Embed (birga — kam, o'zgarmas ma'lumot):
     { _id: 1, ism: "Ali", buyurtmalar: [{ summa: 50000 }, { summa: 30000 }] }
  b) Reference (ishora — ko'p, mustaqil ma'lumot):
     users: { _id: 1, ism: "Ali" }
     orders: { _id: 10, userId: 1, summa: 50000 }   (SQL kabi — 6.3)

Qachon embed, qachon reference — 6.3-bobda chuqur. Qoida: kichik/birga-o'qiladigan embed; katta/mustaqil/ko'p reference.

Misol 3 — SQL CRUD (6.4 ga kirish)

sql
-- Jadval yaratish (qat'iy schema — 2.9)
CREATE TABLE users (
  id SERIAL PRIMARY KEY,           -- avtomatik o'suvchi PK (2.4)
  ism VARCHAR(50) NOT NULL,        -- matn, majburiy
  email VARCHAR(100) UNIQUE,       -- noyob
  yosh INT                         -- son
);

INSERT INTO users (ism, email, yosh) VALUES ('Ali', 'ali@a.uz', 25);   -- qo'shish
SELECT * FROM users WHERE yosh > 18 ORDER BY ism;                      -- o'qish
UPDATE users SET yosh = 26 WHERE id = 1;                               -- yangilash
DELETE FROM users WHERE id = 1;                                        -- o'chirish

Misol 4 — MongoDB CRUD (6.2 ga kirish)

js
// Collection — schema oldindan shart emas (moslashuvchan — 2.9)
db.users.insertOne({ ism: "Ali", email: "ali@a.uz", yosh: 25 });       // qo'shish
db.users.find({ yosh: { $gt: 18 } }).sort({ ism: 1 });                 // o'qish
db.users.updateOne({ _id: 1 }, { $set: { yosh: 26 } });                // yangilash
db.users.deleteOne({ _id: 1 });                                         // o'chirish

// Moslashuvchanlik — turli shakldagi hujjatlar bir collection'da (2.9)
db.users.insertOne({ ism: "Vali", vip: true, manzil: { shahar: "Toshkent" } });

Misol 5 — ACID tranzaksiya (pul o'tkazish — 2.11)

sql
-- Pul o'tkazish: ATOMIK (hammasi yoki hech narsa — 2.11)
BEGIN;                                                    -- tranzaksiya boshi
  UPDATE accounts SET balans = balans - 100 WHERE id = 1;  -- yechish
  UPDATE accounts SET balans = balans + 100 WHERE id = 2;  -- qo'shish
COMMIT;                                                   -- ikkalasi muvaffaqiyatli  saqla
-- Agar orasida xato  ROLLBACK (ikkalasi BEKOR — yarim o'tkazish bo'lmaydi)
-- Bu — ACID Atomicity 2.11-bob; bank/to'lov uchun ZARUR

Misol 6 — DB tanlov qarori (real stsenariy — 2.17)

text
  Stsenariy  Tavsiya:

  Bank/to'lov tizimi       SQL (ACID, yaxlitlik — 2.11)
  E-commerce buyurtma      SQL (bog'lanish, ACID — 2.15)
  Mahsulot katalogi        MongoDB (moslashuvchan — har mahsulot har xil maydon)
  Ijtimoiy tarmoq feed     MongoDB/NoSQL (masshtab, tezlik — 2.16)
  Loglar, analitika        NoSQL (katta ma'lumot — 2.14)
  Kesh, sessiya            Redis (tez — 5.21)
  Blog/CMS kontent         MongoDB (moslashuvchan kontent)
  Qidiruv                  Elasticsearch (matn qidiruv — 2.18)

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

1) Ma'lumotni faylga saqlash (real ilova)

text
 JSON faylga (qidiruv sekin, parallel buziladi — 2.1)
 DB (MongoDB/SQL) — qidiruv, parallel, yaxlitlik

2) "Eng yaxshi DB" deb bittasini hamma joyda

text
 "MongoDB zo'r, hamma joyda ishlataman" (bank uchun yaxlitlik kerak — 2.17)
 vazifaga mos DB (SQL — yaxlitlik; NoSQL — moslashuvchanlik)

3) Bank/to'lovni NoSQL'da (yaxlitliksiz)

text
 pul o'tkazishni eventual consistency bilan 2.12-bob — xato xavfi
 ACID (SQL yoki MongoDB tranzaksiya — 2.11)

4) DB parolini kodga yozish

js
//  kodda (14, 2.20)
mongoose.connect("mongodb://admin:parol123@...");

//  .env
mongoose.connect(process.env.MONGO_URL);

5) Schema haqida o'ylamasdan NoSQL

text
 "schema yo'q, xohlaganimni yozaveraman"  chalkashlik (2.9)
 NoSQL'da ham intizom (Mongoose schema — 6.2); o'ylangan tuzilma

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Noto'g'ri DB tanlovi (keyin qayta yozish)

Sababi: boshda o'ylamasdan tanlash 2.17-bob. Yechimi: vazifani tahlil qiling (bog'lanish? yaxlitlik? masshtab?); shubhada — boshlovchi uchun MongoDB (tez) yoki PostgreSQL (universal, kuchli).

Xato 2 — NoSQL'da murakkab bog'lanishlar bilan qiynalish

Sababi: ko'p JOIN kerak bo'lgan ma'lumotni NoSQL'da 2.16-bob. Yechimi: murakkab bog'lanish — SQL; yoki MongoDB'da to'g'ri modellashtirish 6.3-bob.

Xato 3 — Eventual consistency kutilmagan natija

Sababi: NoSQL'da darrov izchillik kutish 2.12-bob. Yechimi: muhim ma'lumotda tranzaksiya/SQL; eventual mos joyda ishlatish.

Xato 4 — Masshtab muammosi (SQL gorizontal)

Sababi: SQL'ni juda katta yukka gorizontal masshtab 2.14-bob. Yechimi: vertikal + read replica; yoki to'g'ri arxitektura (9); kerak bo'lsa NoSQL.

Xato 5 — Schema migration qiyinligi (SQL)

Sababi: qat'iy schema o'zgartirish 2.9-bob. Yechimi: migration vositasi 6.16-bob; o'ylangan dastlabki dizayn (6.17: ER modeling).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

  • Kompyuter asoslari (0.1, 0.2): RAM vs disk; doimiylik.
  • Backend (5-QISM): DB — ma'lumot saqlash qatlami; har CRUD endpoint DB bilan.
  • Redis 5.21-bob: key-value NoSQL (kesh — polyglot).
  • Auth 5.15-bob: foydalanuvchi DB'da.
  • Graf 3.7-bob: graph DB asosi.
  • MongoDB/Mongoose (6.2, 6.3): keyingi boblar.
  • SQL (6.4-6.13): PostgreSQL/MySQL, JOIN, normalizatsiya, ACID.
  • ORM (6.14, 6.15): Sequelize/Prisma/TypeORM.
  • Arxitektura 9.10-bob: CAP, distributed systems.
  • NestJS 8.3-bob: DB ulanish (TypeORM/Prisma/Mongoose).
  • Xavfsizlik (14): SQL/NoSQL injection, secrets.

8. Eng yaxshi amaliyotlar (best practices)

  • Vazifaga mos DB tanlang (SQL — bog'lanish/yaxlitlik; NoSQL — moslashuvchanlik/masshtab — 2.17).
  • Yaxlitlik muhim bo'lsa — ACID (bank, to'lov — SQL yoki tranzaksiya — 2.11).
  • Ikkalasini ham o'rganing (polyglot — real ilovada ikkalasi — 2.18).
  • NoSQL'da ham intizom (Mongoose schema — chalkashlikdan saqlaning — 2.9).
  • DB kirish ma'lumotlari .env'da (14, 2.20); injection himoyasi.
  • Boshda ma'lumot modelini o'ylang (ER modeling — 6.17); migration rejasi.
  • Indeks (qidiruv tezligi — 6.3); connection pool 6.17-bob.
  • Zaxira (backup) muntazam 2.20-bob; production DB internetga ochiq qoldirmang.
  • Schema o'zgarishini reja qiling (migration — 6.16); CAP'ni tushuning (taqsimlangan — 2.13).
  • Denormalizatsiya/normalizatsiya'ni ongli tanlang 2.10-bob.

9. Amaliy loyiha: "DB Tanlovi va Ma'lumot Modellashtirish"

DB asoslari va to'g'ri tanlovni mustahkamlash. (Bu bob tushunchaviy — loyiha ham tahlil/dizayn.)

Maqsad

Berilgan ilova uchun to'g'ri DB(lar)ni tanlash va ma'lumot modelini (SQL va MongoDB'da) loyihalash — kod yozmasdan, dizayn darajasida.

Talablar (requirements)

  1. Ilova tanlang: e-commerce, ijtimoiy tarmoq yoki yetkazib berish (o'zingiz).
  2. Entity'lar: asosiy ma'lumotlarni aniqlang (foydalanuvchi, mahsulot, buyurtma, sharh...).
  3. SQL dizayn: jadvallar, ustunlar, PK/FK, bog'lanishlar (one-to-many, many-to-many — 2.5).
  4. MongoDB dizayn: collection'lar; har bog'lanish uchun embed yoki reference qaroringizni asoslang (2.10, Misol 2).
  5. DB tanlov tahlili: har entity uchun SQL yoki NoSQL? Nega? (yaxlitlik/bog'lanish/masshtab — 2.17).
  6. Polyglot: qaysi qism Redis (kesh/sessiya), qaysi qism qidiruv kerakligini ayting 2.18-bob.
  7. ACID kerakli joylar: qaysi amallar tranzaksiya talab qiladi (to'lov — 2.11).
  8. Diagramma: ER (jadval bog'lanishlari) yoki document tuzilmasini ASCII bilan chizing.

Maslahatlar (hint)

  • Bog'lanish ko'p + yaxlitlik SQL 2.15-bob.
  • Moslashuvchan/katta ma'lumot MongoDB 2.16-bob.
  • Embed: kichik, birga-o'qiladigan; reference: katta, mustaqil (Misol 2).
  • To'lov/buyurtma ACID 2.11-bob.
  • Kesh/sessiya Redis (2.18, 5.21).
  • "Eng yaxshi DB yo'q" — vazifaga mos 2.17-bob.

"Tayyor" mezonlari (acceptance criteria)

  • Ilova va entity'lar aniqlangan.
  • SQL dizayn (jadval, PK/FK, bog'lanish).
  • MongoDB dizayn (collection, embed/reference asoslangan).
  • Har entity uchun DB tanlovi asoslangan.
  • Polyglot (Redis/qidiruv) o'rni aniqlangan.
  • ACID kerakli amallar belgilangan.
  • ER/document diagrammasi chizilgan.

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

10. Xulosa va keyingi bobga ko'prik

Bu bobda 6-QISMning poydevorini — DB asoslari va SQL vs NoSQL — chuqur o'rgandik:

  • Nega DB (fayl yetmaydi — qidiruv/parallel/yaxlitlik — 2.1); doimiylik (disk — 2.2).
  • Ikki dunyo: SQL (relatsion — jadval/qator/ustun, bog'lanish/FK, SQL tili — 2.4-2.6) vs NoSQL (4 tur; document/MongoDB — collection/document — 2.7, 2.8).
  • Schema (qat'iy vs moslashuvchan — 2.9); normalizatsiya vs denormalizatsiya 2.10-bob.
  • ACID (SQL yaxlitlik — 2.11) vs BASE (NoSQL mavjudlik — 2.12); CAP 2.13-bob; masshtab (vertikal vs gorizontal — 2.14).
  • Qachon qaysi biri 2.17-bob; polyglot (ikkalasi birga — 2.18); xavfsizlik 2.20-bob.

Keyingi bob — 6.2-bob: MongoDB va Mongoose — CRUD, schema, model, query. Nazariy poydevorni qo'ydik; endi amaliyotga o'tamiz. Eng mashhur NoSQL — MongoDB va Node.js uchun ODM — Mongoose bilan ishlashni o'rganamiz: ulanish, schema, model, CRUD amallari, va so'rovlar (query). JS bilan tabiiy ishlaydigan, tez boshlanadigan DB.

Foydalanilgan rasmiy/ishonchli manbalar

  • IBM — SQL vs NoSQL Databases; designgurus — SQL vs NoSQL key differences
  • AWS / phoenixNAP — ACID vs BASE database models; Medium — CAP theorem & PACELC
  • tech-insider — SQL vs NoSQL 2026 (use cases, scaling)

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
6.1-bob: Ma'lumotlar bazasi asoslari — SQL vs NoSQL — Wisar