SQL Trigger

SQL Trigger - insert, update, (truncate) yoki delete operatsiyalaridan sodir bo'lgandan oldin yoki keyin avtomatik ishga tushuvchi funksiya xisoblanadi. Ular tablega bog'liq funksiya xisoblangani uchun, avval trigger function yaratasiz va uni biror tablega bog'lab qo'yasiz.

Types
PostgreSQL, MySQL asosan 2 turdagi triggerlarni taqdim qiladi, row-level va statement-level trigger. Ikkisini bir-biridan farqi necha marta va qaysi vaqtda ishga tushishida. Oddiyroq misol keltiradigan bo'lsak, 100 ta ma'lumot insert qilayabsiz demak row-level 100 marta ishlasa statement-level 1 marotaba ishlaydi.

Hozirda ba'zi ORMlar ham event sodir bo'lishidan oldin yoki keyin qandaydir ishlar qilish imkoniyatini berishini bilishingiz mumkin misol uchun SQLAlchemy va Django ORM. Django signals bu triggerni ORM level implementatsiyasi xisoblanadi. Ishlashi database-level triggerga o'xshaydi va siz pre_init, post_init, pre_save, post_save kabi signal turlari bilan o'zingiz hohlagan vaqtda biror logikani amalga oshirishingiz mumkin.

Problems with triggers
Triggerni kamchiliklari yo'q ammo dasturchilarda bor chunki hamma narsani ham triggerga berish xato. Triggerdan faqat kerak bo'lgan xolatdagina foydalanishni tavsiya qilaman. Ba'zan noto'g'ri yozilgan trigger juda ko'p muammolarga olib kelishi mumkin chunki ular avtomatik ishga tushgani uchun sizga ko'rinmaydi. Ba'zan esa ko'plab foyda olib kelishi mumkin ya'ni ishingizni, vaqtingizni tejashi mumkin.

@otabekswe

SQL View

Complex querylarni qayta-qayta yozishdan yoki copy/paste qilishdan charchagan data engineerlar SQLga shikoyat yozibdi. SQLni yaratgan jamoa esa bu muammoga yechim izlashga kirishadi. Yechim sifatida esa bizga View terminalogiyasini taqdim qiladi. (Ertaknamo boshlanish 😉)

SQL View - bu virtual table bo'lib u o'zida ma'lumot saqlamaydi balkim bir yoki bir nechta tablelarni olib keladi (albatta databasedan). View orqali complex (qiyin) querylarni bo'laklarga bo'lish orqali soddalashtirish va ularni more managable qilish mumkin. Ularga access limit ham berish mumkin, zo'r-a?

Types of Views
SQLda 2 turdagi viewlar mavjuda va ular: Regular views va materialized views xisoblanadi.

Regular views - bu oddiy view bo'lib, bir nechta tablelardan ma'lumot olib kela oladi ammo shu bilan birga JOIN, SUBQUERY va boshqa turdagi statementlar bilan ishlatiladi.

Materialized views - biror viewdan olib kelingan ma'lumotlarni physical copysi xisoblanib, ular alohida tableda saqlanadi.

Real life examples
Tabledan qanday ma'lumotlarni select qilsangiz viewdan ham shunday qilasiz ammo farqi view sizga uzundan-uzun va complex querylarni qayta yozib o'tirmasligingiz uchun juda katta yordam beradi. Misol uchun E-commerce website yasasangiz, customerlarga buyurtma va yetkazib berish uchun alohida-alohida saqlangan ma'lumotlarni birlashtirib single view orqali chiqarib berishingiz mumkin. Bunda misollar juda ko'p.

Conclusion
Gapni indallosi sifatida, view xuddi o'zgaruvchidek gap. Siz unga queryni saqlaysiz va har safar queryni emas balkim viewni chaqirasiz, u esa sizga o'sha queryni beradi.
✅
SELECT id, name, order_no FROM customer_view;

❌
SELECT id, name, order_no FROM (SELECT customer.id, customer.name, orders.number AS order_no FROM customer JOIN orders ON customer.order_id = orders.id) AS customer_view;

@otabekswe

Hech qachon Senior bo'la olmaydiganlar

Har bir soxani eng zo'r mutaxasislari bo'lganidek eng yomonlari ham bo'ladi. Bunday insonlarni ajratib olish umumman qiyin emas shunchaki ularni ba'zi xislatlari ularni hech qachon rivojlanmasligini ko'rsatib beradi. Keling ularni birma-bir sanab nima uchun bunday xulosaga kelganimni aytib beraman.

1. Google qilishni bilmaydiganlar - Internetda hozirda oddiy va suyqasi chiqib ketgan savollarga ming xil javob olishingiz mumkin. Agar siz "JavaScript nima?" "For loop qanday ishlaydi?" kabi savollarni odamlardan so'rayotgan bo'lsangiz tabriklayman, siz shu insonlar qatoriga kirdingiz.

2. Unutuvchilar - Kechagi xatosi, o'rgangan mavzusi yoki nima bo'lsa ham uni tez unutsa demak bu toyifa ham rivojlanmaydi. "Qonunlar qon bilan yozilgan" degan naql bor. Ya'ni ba'zi qonunlarni bilmasangiz yoki unutsangiz qon to'kishingizga to'g'ri keladi. Unutmaslik uchun esa ko'proq yaxshiroq izlanib amaliyot qilish juda zarur.

3. Ma'suliyatsizlar - Har bir odamni jamoada o'z ma'suliyati va majburiyatlari bo'ladi. Ulardan qochish, yaqinlashmaslik yoki yechim qidirmaslik tajribadan quruq qolish bilan barobar. Bir kunmas-bir kun agar sizni hech kim jamoaga qo'shishni xohlamasa xafa bo'lmang, chunki siz ma'suliyatsizlik qilasiz va hech kim sizga nimadirni ishonib topshirgisi kelmaydi.

4. Taqqoslovchilar - Tez-tez language, framework yoki toolarni bir-biri bilan solishtirib yomonlovchilarni eshitib qolamiz. Bu ham shunday dasturchilardan dalolat. Computer Science olamida qurollar juda ko'p ammo eng qulayidan foydalanish dasturchiga borib taqaladi. Nima uchun Google C++, Java ni ko'proq ishlatishini sababi ular boshqalariga qaraganda ulardagi muammoga ko'proq, efficientroq yechim deb topilgani uchun. Ko'p ish yoki kam ish deb ajratish ham yomon, btw.

5. General bilmlardan qochuvchilar - Faqat dasturlash tili, frameworkga bog'lanib qoladigan va umumiy bilimlarni o'rganmaydiganlar ham shu insonlar safida bo'ladi. Umumiy bilimlar aslida bu narsalar nima, qachon va qayerda to'g'ri ishlatish mumkinligini sizga o'rgatadi. Muammoga turli-xil prespectivedan qarash imkonini beradi. "Ularni qayerdan o'rganaman?" deysizmi, albatta kitoblardan. Demak xulosa kitob o'qimaydiganlar ham pro bo'la olmaydi.

Bu postni ko'pchilik xatto o'qimaydi ham, o'qisa ham bir kunmas-bir kun esdan chiqaradi. Ammo maqsadim 2ta odam o'qisa ham ularga katta ta'sir qilib zo'r rivojlanishsa men roziman.

P.S: Fikrlar o'ta subyektiv va ba'zilari (balkim barchasi) noto'g'ri bo'lishi mumkin. Let me know if am wrong!

@otabekswe

How Database Stores Data

Database internally ma'lumotlarni Heap file ichiga saqlab boradi. Har bir row esa item (tuple) ko'rinishida bo'ladi. Heap file esa bir nechta pagelardan iborat bo'ladi va har bir page qanchadir miqdordagi (rowlar) ma'lumotlar saqlanadi. Ya'ni bizda bitta table bor degani bu bizda o'sha tabledagi ma'lumotlarni saqlash uchun heap file bor degani. Heap file ichida esa bir nechta page(block)lar ham bo'ladi.

Endi tasavvur qiling, kimda age > 30 bo'lsa barcha ma'lumotlarni taqdim qilishini so'radik. PostgreSQL kimni yoshi nechidaligini bilmaydi, shuning uchun avval u barcha rowlarni RAMga olib keladi va list shakliga olib o'tadi (majoziy ma'noda list deyildi). Endi shu listdan har bir rowni birma-bir kirib tekshiradi va kimda age > 30 bo'lsa o'shalarni olib qaytaradi. Hop ammo bu yerda katta minus bor. Agar tasavvur qiling bizda rowlar soni millionlab bo'lsachi, ma'lumotlarni RAMga olib kelish juda qimmatga tushadi.

Xulosa: Bu juda qisqacha ta'rif bo'ldi ammo ko'proq o'rganish uchun esa ushbu manbadan ko'rib chiqishingiz mumkin:
- storage page layout

@otabekswe

How database indexing works

Tasavvur qiling yonimda 1000 betli kitob, Sarah va Lisa turibdi. Men Sarahga qarab "Hey, men seni seva... e uzur, menga Hamlet asarini topib ber shu kitobdan" dedim. U varoq titkilashga o'tdi. Ho'sh u asarni topganicha men zerikib ketib u bilan bo'lgan aloqani uzvordim. Chunki juda sekin qidirardi.

Endi esa Lisaga qarab xuddi shunday murojaat qildim. Lisa aqlli edi shuning uchun u darrov mundarija (book index) ni ochdiyu Hamlet asarini nechanchi pageda joylashganini topib menga o'sha pageni darrov ochib ko'rsatdi. Men uni yana ham yaxshi ko'ra boshladim.

Bu hikoyadan keyin siz "haa, database indexing shunday ishlar ekanda" deyayotgan bo'lsangiz shoshilmang, qisman ha ammo to'laqonlik unday emas. Keling internally nimalar bo'lishi haqida to'xtalib o'tamiz.

What is an Index?

Well, o'tgan maqaolada database barcha ma'lumot(page)larni RAMga olib o'tib keyin birma-bir ko'rib chiqishi haqida gaplashgandik va agar bizda millionlab rowlar bo'lsa bu bizga qimmatga tushishini tushungandik. Agar biz barcha pagelarni emas balkim aniq bir pageni olib o'tsakchi? Aynan shu ish indexing deyiladi. Bilamizki pagelarda qanchadir miqdorda cheklangan rowlar bo'ladi va biz bir necha pagelarni RAMga yuklab har bir pageni scan qilishimiz emas, shunchaki bitta pageni olamiz va undagi rowlarni qarab chiqish orqali operatsiyalar sonini sezilari tushirishimiz mumkin bo'ladi, voila 🤲 (Khabiyni qo'li)

Cost of Indexing

Indexing operatsiyalar sonini tushuradi va boshqa tomonnikini ko'taradi🥲. Misol uchun CRUD operatsiyalaridan Read qilish tezlashgani bilan CUD (Create, Update, Delete) uchun qo'shimcha ishlar paydo bo'ladi. Oldin faqat tablega ma'lumot yozsangiz endi indexga ham yozasiz va qancha ko'p index bo'lsa shuncha ko'p operatsiya bo'ladi.

Post foydali bo'lgan bo'lsa uni share qilmang, bu juda xavli. Hamma senior bo'lib ketmasin deymanda 😉

@otabekswe

Ushbu ko'rib turgan funksiyalaringiz siz pythonda sevib ishlatadigan logical operatorlar.

Ularni implement qilish uchun print ichidagi ifodalarni run qilib ko'ring (stringsiz) va keyin men tuzgan funksiyalar bilan run qilib ko'ring.

Qarabsizki bir xil natija olasiz. Savol endi ham math kerak emasmi?

For more

@otabekswe

API Throttling

Hop, menimcha ushbu postni o'qib turgan barcha insonlar API nimaligi haqida bilishadi. API Throttling - API ga yuboriladigan requestlar sonini qanchadir vaqt oralig'i uchun cheklash. Tasavvur qiling telegramda xabar yozib yuborish uchun ko'k "samalyotcha"ni bosdingiz ho'sh bu yerda nimalar sodir bo'ldi?

Ushbu jarayonda o'sha "samalyotcha" event sodir bo'lgani haqida xabar topadi va API ga request yuboradi (albatta xabaringiz o'sha request ichida ketadi). API esa telegram web serveri bilan bog'lanadi va ushbu buttonni vazifasi nima uchun bo'lsa o'sha vazifani bajarishga kirishadi (ya'ni server sizni xabaringizni oladi va boshqa user, bot yoki e.t.c. ga jo'natadi).

Throttling faqat Backendga yoki APIga tegishli yechim emas balkim umumiy callable larga tegishli. Misol uchun Frontend da ham throttling qilish mumkin ya'ni siz dasturlash tiliga "hey mana bu funksiyani har minutda faqat 5 marta chaqrishga ruxsat ber" deysiz tamom (kod yozish bilan aytasizda).

Ko'p xolatlarda resurs tejashlik maqsadida ko'proq ishlatiladi chunki keladigan requestlarni barchasiga server javob berishi orqali ko'p resurs sarflanadi (downtime). Misol uchun Leetcode subscription sotib olmasangiz code run qilishingiz uchun rate limit ya'ni cheklov o'rnatib qo'yadi. Bu ham aynan throttle qilish orqali yuzaga keladi.

Ko'proq bu yerdan...

@otabekswe

Application Layer (part-1)

Backendga Sayohat loyihasi davom etadi. Endigi navbat OSI modelini eng yuqori qavati "application layer"ni kashf qilishga.

Ba'zi joylarda adashgan yoki xato qilgan bo'lsa izohlarda aytib o'ting.

Post foydali bo'lgan bo'lsa bizni duo qilib turing )

@otabekswe

Nima uchun FAANGda DS Algo bo'yicha interview qilishadi?

FAANG kompaniyalariga shu paytgacha 5ta interview qilishga ulgurdim va 4tasidan rejact bittasi bilan davom etayabmiz (hozircha sir 😉). Intel, Amazon, Nokia va Bank of New York Mellon kompaniyalarida ham bir xil DS Algo interviewlari bo'ldi. Xo'sh interview oxirida 2ta ajoyib insonlar bilan connection qilib oldim va savollar berdim. Bulardan biri bu "Nima uchun FAANGda DS Algo bo'yicha interview qilishadi?" Javoblarni umumiy va soddalashtirib quydigachi xulosalarga keldim:

1. Problem analysis - Dasturchilar muammolarni yechuvchi insonlar bo'lgani uchun ham ulardan kuchli "muammo tahlil qilish" ko'nikmalari talab qilinadi. Bu orqali esa dasturchi qachon, qayerda va qanday qilib muammoga to'g'ri yondashuv qila olishini kuzatish mumkin.

2. Language proficiency - Dasturchilarda til borasidagi bilimlari bo'yicha savollar berib o'tirgandan ko'ra, ularni amaliyotda qanchalik to'g'ri va moxirlik bilan ishlata olishini tekshirish osonroq ekan. Tasavvur qiling siz nazariyda zo'r bilimga egasiz ammo amaliyot qilib ko'rmagansiz, bu yomon va ushbu muammoni oldini olish uchun sizdan ko'proq amaliy vazifalar berish orqali aniqlash ancha vaqtdan yutish imkonini beradi.

3. Soft skills - Jamoaga sizni kiritishdan oldin sizni qanday soft skillga egaligingizni tekshirish uchun ham bu interviewlar juda zo'r, chunki muammo aniq, yechim uchun sizda ko'plab aniq va sodda fikrlar so'raladi. Siz qanchalik yaxshi tushuntirish qobilyatiga ega bo'lsangiz, qanchalik muammoni yechimini sherigingiz (interviewer) bilan tahlil qilsangiz shuncha yaxshi soft skillga egasiz degani )

... va boshqa sabablar ham bor, ammo eng asosiylar menimcha shular.

Latofat Bobojonova: Internship qilish uchun tajriba emas yaxshi project(lar) va kuchli bilm bo’lsa yetadi. Sinab ko’rilgan uslub :)

P.S: Ushbu postni o'z tajriba va fikrlarim asosida yozayabman

@otabekswe

#TechTalks

Google kompaniyasida 2 marotaba ketma-ket internship (amaliyot) qilgan o'zbek qizi, va loyihamizning birinchi mexmoni Latofat Bobojonova bilan o'zgacha suxbat.

Ushbu suhbat ochiq, samimiy va boshqalaridan qiziq bo'ladi.

Vaqt: 18:00 (Toshkent vaqti bilan)
Sana: 22-Oktyabr
Mavzu: Life at Google

@otabekswe

Speaker: Latofat Bobojonova
Topic: Life at Google
Duration: 55 minutes

Database normalization

Database implement qilishdan oldin juda puxta va uzoq fikr qilishni tavsiya qilaman. Chunki har bir o'zgartirish yoki yangi qo'shimchalar kiritish sizga qimmatga tushishi, ba'zan esa katta muammolar ham keltirishi mumkin. Xuddi shunday muammolarni keltirib chiquvchi omillardan biri bu ne-normal database xisoblanadi.

Database normalization - ma'lumotlarni tartibli va izchil tarzda orginize qilish uchun ma'lumotlar bazasini dizaynlash tamoyili. Keling misollar bilan ko'rib chiqamiz.


1NF - First Normal Form

Birinchi normal formada ma'lumotlar atomic va unique bo'lishi kerak bo'ladi va uzunroq qilganda ushbu prinsiplarga amal qilishi kerak:
- hech bir cell bittadan ko'p ma'lumot saqlamasligi kerak (atomicity)
- identifikatsiya qilish uchun primary key bo'lishi kerak
- duplicate row yoki column bo'lmasligi kerak
...

Tasavvur qiling, foydalanuvchini "Address"ini saqlamoqchisiz. Siz nazarda tutgan "Address" = "Toshkent shahar, Mirobod tumani, Amir Temur ko'chasi, 56 uy" ammo yuqorida aytilganidek atomicity bo'yicha bunday ma'lumot saqlash yaxshi emas. Siz buning o'rniga manzillarni saqlash uchun alohida table yaratasiz va saqlangan ma'lumotni user tabledagi user_id ga foreign key sifatda aloqasini ta'minlaysiz, tamam )


2NF - Second Normal Form

Birinchi normal forma asosan uniqueness va atomicity ga e'tibor qaratsa, Ikkinchi normal forma redundancy and data dependency ni ta'minlashga ximzt qiladi:
- 1NF ni saqlab qolgan holatda ishlashi kerak
- Barcha non-key attributelar faqat primary-keyga dependen bo'lishi kerak.
...

Tasavvur qiling, kutubxona uchun database qildingiz. Sizga keladigan ma'lumotlar asosan kitoblar va avtorlar haqida bo'ladi. Ya'ni bitta avtor ko'p kitob yozishi yoki bitta kitob ko'p avtorlar tomonidan yozilgan bo'lishi mumkin. 2NF da huddi shu muammoni 1NF dan kelib chiqib hal qilasiz. Ya'ni books va authors degan tablelar yaratasiz. har bir kitob uchun book_id bo'lsa, avtor uchun author_id bo'ladi. Bu degani ManyToMany relationshipni endi juda osonroq yo'l bilan yecha olasiz degani. book tableda avtor haqida ma'lumotlarni author tablega, author tableda book haqida ma'lumotlarni olish uchun book tablega foreign key qilasiz holos, tamam.

Post juda cho'zilib ketmasligi uchun qolganlarini o'zingizga sovg'a qilaman, oling va meni eslab yuring (so'kinmasdan)🎁.

@otabekswe

Oltinga teng loyihalar

Ilm olishni hamma eplaydi. Ammo olingan ilm orqali muammolar yechishni hamma ham eplay olmaydi.

Loyiha qilish menga kompaniya bera olmaydigan tajribalarni bergan. Ayniqsa yangi til va texnologiyani tez o'rganib ketishimga sababchi bo'lgan.

Misol uchun:

gylo - Ushbu loyiha menga Cloudflare bilan interviewni olib bergan loyiha xisoblanadi

Menda bunday qiziq loyihalar ko'p afsuski ular private, rasmiyatchilikda aylanay 😉

Tez orada ba'zilarini public qilish niyatidaman. Ammo hozircha dsalgo.uz ustida ishlayabman )

@otabekswe

Kamchilik nimada?

Bir tanishim bilan project qilish bo'yicha suxbat qilib ba'zi fikrlarni muhokama qildik. Hozir ishga topshiruvchilarni fail bo'lishini asosiy sababi ular qilayotgan yoki qilishni istagan projectlarda ekan.

Kimni qarasa E-Commerce, VideoStream ishlarni qilishadi. Vaxolangki bunda projectlarga misollar internetda qalashib yotibdi va eng qiziq tomoni shundaki soxani chala o'rganib olib, kodlarni ko'chirib, tutorialga ergashib qilgan ishini githubga "kerilib" yuklab qo'yishadida "mana shunday ishlar qilganman" deyishadi.

Kompaniyalarda ko'p shunday projectlar qilinishi to'g'ri ammo bu degani siz ham shunday ish qilishiz kerak degani emas. Loyihalar qachon ko'zga tashlanadi qachonki biror ishni nargisidan (loyihadan) yaxshiroq qila olsa. Yoki ko'pchilik qilmaydigan ishlarni qilishda misol uchun DB yaratib ko'rish, tool yaratish generic ishlatish uchun.

Loyiha yasang, faqat o'zingiz uchun emas barcha uchun xizmat qiluvchi loyiha yasang. Bor loyihani qayta yasang, ammo sizniki qaysidir jihatlama yaxshiroq bo'lsin narigisidan.

@otabekswe

Davis Steve: Falcon 1 raketasi uchun aktuator kerak!
Elon Musk: Necha pul ekan bozorda?
Davis Steve: 120 000$
Elon Musk: Garajning qulfi kabi sodda matox bu, bor o'zing yasa. Tannarxi 5 000$ dan oshmasin!

⏰ 9 oydan so'ng:
Davis Steve: Aktuator yasadim va narxi 3 900$ ga tushdi
.
.
2004 - yil Ilon Mask va SpaceX injeneri Stiv Davis o'rtasidagi suxbat ekan.
Ilon Mask boshqalar oddiy qabul qilib ketgan narsalarni ham so'roqga tutib ko'p texnologiyalarni 0 dan yaratishga sababchi bo'lgan ekan.

@otabeknurmatov_1

#TechTalks 2-soni efirda!

Applied Labs kompaniyasida Software Engineer bo'lib ishlagan, Backend va Data Engineering sohasiga aloqador ko'plab foydali postlar yozgan mexmon - Bobosher Musurmonov bilan o'zgacha suxbat.

Ushbu suhbat ochiq, samimiy va boshqalaridan qiziq bo'ladi, ishonavering. Sizga qiziq bo'lgan savollarni esa izohlarda qoldiring.

Vaqt: 21:00 (Toshkent vaqti bilan)
Sana: 26-Noyabr
Mavzu: Trip to Database internals

@otabekswe