Firebase Firestore bilan tanishuv va ma'lumotlar bazasini loyihalash

Cloud Firestore nima?

Firebase ikkita ma'lumotlar bazasini (database) taklif qiladi: Realtime Database va Cloud Firestore. Realtime Database - bu eski texnologiya hisoblanadi. Zamonaviy ilovalarning aksariyati Cloud Firestore'ni tanlashadi, chunki uni ishlatish osonroq, kuchliroq qidiruv (querying) imkoniyatlariga ega va cheksiz masshtablana oladi (scalable). Apple'ning CloudKit texnologiyasi bilan solishtirganda, Firestore'ni sozlash va ishlatish sezilarli darajada sodda hisoblanadi, hamda u Android va Web uchun ham mos keladi.

Baza yaratish

Firebase Console'ga kirib Firestore Database bo'limidan Create database ni tanlang:

1. Security rules: Boshlanishida "Test mode"ni tanlang (bir oygacha hamma bemalol yozib-o'qishi mumkin). Kelajakda ularni xavfsiz holatga o'tkazamiz.
2. Server joylashuvi: Ilovangiz foydalanuvchilarining katta qismi qayerda yashasa, o'sha hududga eng yaqin serverni tanlang (Masalan, Europe yoki United States). Diqqat: buni keyinroq o'zgartirib bo'lmaydi!

Firestore strukturasi

Firestore NoSQL turidagi ma'lumotlar bazasi bo'lib, u ikki asosiy tushunchaga asoslanadi: Collection (To'plam) va Document (Hujjat).

• Collection: Bu papka (folder). Papka o'z ichida cheksiz miqdordagi hujjatlarni saqlashi mumkin.
• Document: Bu aniq bir ma'lumot yozuvi (masalan, bitta foydalanuvchi profili). Har bir hujjat o'z ichida maydonlarni (Fields) saqlaydi.
• Qoida: Collection ichida faqat Document'lar bo'ladi. Document ichida esa Collection'lar bo'lishi mumkin (Sub-collection).

Hujjat hajmi uchun limit: Bitta hujjat eng ko'pi bilan 1 Megabayt joy egallashi mumkin (bu taxminan 1 millionta harf degani). Collection ichidagi hujjatlar soni esa mutlaqo cheklanmagan!

Data tiplari va Nomlash qoidalari

Hujjat ichidagi maydonlar turli xil bo'lishi mumkin: String, Number, Boolean, Array, Map (Dictionary), GeoPoint (Kenglik/Uzunlik), Timestamp (Sana).

Juda muhim qoida: Swift'da biz o'zgaruvchilarni camelCase ko'rinishida yozishga o'rganganmiz (masalan, isHealthy). Lekin ma'lumotlar bazasida iOS, Android va Web jamoalari bir xil tushunishi va muammo chiqmasligi uchun nomlarni snake_case da (masalan, is_healthy) yozish qabul qilingan best-practice hisoblanadi. Biz ham shunga amal qilamiz!

Arxitekturani loyihalash (Misollar)

Deylik, biz "Foydalanuvchining bozorlik ro'yxati"ni (Grocery List) bazada saqlamoqchimiz. Buni bazada 3 xil usulda qursak bo'ladi:

1-usul: Oddiy Array (Users hujjati ichida)

users kolleksiyasida user_1 hujjati bor. Uning ichida grocery_list: ["Apple", "Orange"] degan massiv ochamiz.

• Afzalligi: O'qish juda tez. Bitta so'rov orqali hamma narsa keladi.
• Kamchiligi: Mevalar haqida qo'shimcha ma'lumot (masalan, sotib olindimi, narxi qancha) saqlab bo'lmaydi, faqatgina matnlar ro'yxati.

2-usul: Sub-collection (Hujjat ichidagi kolleksiya)

users -> user_1 hujjati ichida yangi -> grocery_list degan kolleksiya ochamiz. Bu kolleksiya ichida har bir mahsulot alohida hujjatga aylanadi.

• Afzalligi: Har bir mahsulot hujjat bo'lgani uchun ularga qo'shimcha priority: "high", is_bought: false kabi xususiyatlar qo'shish mumkin. Kolleksiyadagi hujjatlar cheksiz bo'lishi mumkin.
• Kamchiligi: Bu ma'lumotlarni faqatgina o'sha user_1 ning o'zi ishlatayotganda qulay, agar boshqa do'sti bilan ro'yxatni baham ko'rmoqchi bo'lsa (shared list), uni tashqaridan o'qish qiyin bo'ladi.

3-Usul: asosiy collection (Top-level)

Asosiy strukturada users kolleksiyasi bilan bir qatorda grocery_lists degan yangi mustaqil kolleksiya ochamiz. Har bir ro'yxat hujjati ichida kimga tegishli ekanligini bildiruvchi author_id: "user_1_id" maydoni bo'ladi.

• Afzalligi: Ommaviy suhbatlar (chat), ommaviy postlar yoki baham ko'rilgan ro'yxatlar uchun eng to'g'ri usul! "Barcha ro'yxatlar ichidan author_idsi sening ID'ingga teng bo'lganlarini tortib ol" degan so'rov (query) yozish orqali ma'lumot topiladi.
• Kamchiligi: Eng murakkab usul. Oldingisiga qaraganda qidiruvlar soni ortishi mumkin.

Xulosa

Qaysi usul eng yaxshi degan savolga "Sizning ilovangiz ma'lumotlarni qanday o'qib olishiga (fetch) qarab" deb javob beramiz. Ko'p hollarda bizga Collection -> Document -> SubCollection -> Document strukturasi (2-usul) to'g'ri keladi va bu eng keng tarqalgan "best practice" hisoblanadi.

Ushbu darsda biz barcha jarayonlarni shunchaki Web interfeys orqali o'rganib chiqdik. Keyingi darsda biz bazani tozalaymiz va bu narsalarni Xcode ichida Swift kodi orqali qanday yaratish va o'qib olishni boshlaymiz!