SQL Join - endi easy

Ushbu maqolani o'qib chiqish orqli JOIN haqida o'rganib, practice qilib chiqishingiz mumkin.

Sizga qiziq mavzularni commentda yozib qoldiring balkim keyingi post aynan shu mavzu haqda bo'lar...

Ma'qolani o'qish tekin 🙂
.
.
.
.

Subquery - endi easy

Ushbu maqolada Subquery mavzusini yaxshilab o'rganib, practice qilib chiqishingiz mumkin.

O'sha gap: Ma'qolani o'qish tekin 🙂
.
.
.
Erinmasangiz post haqida feedback kutib qolaman )

Tutorial hell

Qiziq maqolalar ichida tutorial hell degan yozuvli maqolaga ko'zim tushdi. Kirib o'qib chiqdim va bugun shu mavzuda post yozishga qaror qildim.

Tutorial hell - qachonki siz biror resurs (video, article va ...)dan kim nimani o'rgatsa shuni ko'r-ko'rona ko'chirishingizga aytiladi. Ushbu muammoga yangi dasturlashga kirganlar yoki biror yangi texnologiya, til o'rganayotganlar tez uchrashar ekan va bu rost.

Aslini olganda bu juda yomon chunki hozir haqiqatdan ham ko'plar nima qilayotganiga tushunmay kod yozadi yoki ko'chirishadi, "I have no idea what am doing bro" deganlari shu bo'lsa kerak. Bu kasallikni eng katta yomon ta'siri dasturchi o'rgangan narsasini faqat qilgan ishiga bog'lab o'rganadi va boshqa mustaqil ish bersangiz ... (Loading...)

Dasturlashda deyarli 60-70% tushunchalar boshqa narsalarda ham mavjud bo'ladi va ularni faqat bitta til, texnologiya yoki narsaga bog'lab o'rganish juda xato deb bilaman.

Tez yangi narsa o'rganishni emas balkim bor narsani kuchaytirishni o'rganing. Bruce Lee akam aytganidek:

"Men 1000 xil zarba biladigan raqibdan emas,
Bitta zarbani 1000 marta qaytaradigan raqibdan qo'rqaman."

Let me know if am wrong )

@otabekswe

CTE - endi easy

Ushbu maqolani o'qib chiqish orqli CTE haqida o'rganib, practice qilib chiqishingiz mumkin.

Yana o'sha gap: Ma'qolani o'qish tekin 🙂

Bundan keyingi mavzular advanced topikda qilishga qaror qildim chunki tutorial yozish unchalik ham yoqmadi
.
.
.

Dasturchi universitetda o'qishi shartmi?

Menda ham shunday savol paydo bo'lib unga javob qidira boshladim. Ushbu savolga o'tgan yili Yaponiyalik professorimdan ajoyib javob olgandim. Uning javobi shunday bo'lgandi:

"Otabek, Dasturlash bu computer sciencedagi kichik bir qism xolos. Har narsani dasturlash bilan hal qilib bo'lmaydi ammo computer science bilan ko'plab ishlar qilish mumkin. Sen hozir o'rganayotgan math, networks va ... fanlar sizlarga fundamental, tubdagi tushunchalarni o'rgatayabdi. Dasturlash tili esa bu shunchaki tool va uni hamma o'rgana olishi mumkin. Computer science problem sovlingdan iborat, faqat dasturlashdan emas" degandi.

Ushbu gaplardan keyin juda ko'p o'ylanib faqat oldimdagi narsaga focus qarata boshladim. Boshlanishiga OOP darsimizda Alan Key qanday qilib OOPga asos solgani, Simula, C++ va uning maqsadi haqida gaplashgandik. Keyin ustozimdan maslahat olib Object Thinking by David West kitobini o'qishni boshladim. Ko'p narsalarni anglab yetdim. Biroz vaqt o'tib Azimjon aka bilan gaplashib ulardan Elements of Reusable Object-Oriented Software kitobini o'qib chiqish haqida tavsiya oldim, o'qib yana ham ko'proq narsa o'rgandim.

Keyinchalik Computer Networks darsimizdan Networking o'rgana boshladim, juda qiziq bo'ldi va ko'p biz bilamagan ishlar asosan shu tushunchalar asosida ishlashiga tushundim.

Xulosa: Computer Science faqat dasturlash tillari yoki webdan emas balkim ko'plab chiroyli jabhalardan iboratligini tushunishingiz kerak. Va 4 yil universitetda o'qish bekochilik emas.

P.S: Fikrlarim o'ta shaxsiy va 100% to'g'ri bo'lmasligi mumkin (balkim aniqdir bilmayman).

@otabekswe

Declarative vs Imperative Programming

Ushbu 2 paradigm paradigmlar asosi xisoblanadi desam mubolaga' bo'lmaydi chunki Paradigmlar aynan shu 2ta turga ajraladi. Misol uchun OOP, FP bu Declarative xisoblansa, Procedural va OOP (haqiqiy OOP emas) Imperative xisoblanadi. Hop keling ikkisini farqini tushinib olsak.

Imperative Programming

Imperative Programmin is about "HOW a program works". Aniqroq tushunchada aytadigan bo'lsa siz sochizni oldirayabsiz. Sartaroshga qarab:

"Xullas oka, sochni orqasini ozgina, ikki yonini kaltaro va ustini uch-uchuidan olib qo'ying." deyishingiz bu har bir qadamni qanday bajarishni aytishga to'g'ri keladi va sartarosh ham xuddi shunday oladi. Shu narsa Imperative Programming deyiladi. Pythonda example keltiradigan bo'lsak

total = 0
nums = [1, 2, 3, 4, 5]
for num in nums:
total += num

Ushbu kod aynan imperative xisoblanadi chunki har bir stepni siz tasvirlab berayabsiz qanday bo'lishini.

Declarative Programming

Declarative Programmin is about "WHAT a program does". Yana o'sha sartarosh oldidasiz, ammo bu safar siz unga qarab:

"Xullas oka, sochimni mana bunga o'xshatib qo'ying." deyishingiz bu qanday qilishini farqi yo'q ammo shunday natija bersa bo'ldi deganday gap.

nums = [1, 2, 3, 4, 5]
total = sum(nums)

Ushbu kod aynan declarativega to'g'ri keladi chunki siz steplarni keltirmayabsiz qisqacha qanday natija xohlashizni aytayabsiz xolos.

It's all about Abstraction

Barchasi borib abstractionga taqaladi chunki bizga uni QANDAY ishlashi emas balkim NIMA qilishi ya'ni ishlashi muhim deyishday gap.

Post idea chopildi, rozi bo'lasiz )

@otabekswe

Database Transaction

The Problem
Anna databasega id=1 teng kitob chiqarilgan sanasi (release_year)ni olish uchun query yozdi va unga 2004 javobi qaytdi. Xuddi shu vaqt Sam shu kitobni chiqarilgan sanasini (2012) va nashrini (4-nashr) o'zgartirish uchun query yozdi. Anna biroz vaqtdan keyin yana shu "release_year"ini oldi va natija bu safar o'zgarib qoldi. Biroz vaqt o'tib esa Sam adashganini sezib ROLLBACK qilib yubordi.

The Solution
Transaction ma'lumotlarni "consistency"si bilan bog'liq muammolarni oldini olish uslubi xisoblanadi. U ACID tamoyili bo'yicha ishlashi kerak va transaction konseptsiyasidan asosiy maqsad transaction tugagunicha butun bir jarayonni izolyatsiyalash xisoblanadi. Xo'sha ACID nima?

ACID
ACID bu Atomicity, Consistency, Isolation va Durability.

Atomicity
Qachonki transaction (read/write) sodir bo'lsa, barcha operatsiyalar bir vaqtning o'zida sodir bo'lishi kerak yoki umuman bo'lmasligi kerak. Agar transaction to'xtatilsa yoki xatolik yuz bersa, databasega ta'sir qilmasligi kerak va butun jarayon oldingi xolatiga qaytishi kerak. Xuddi shunday, agar transaction amalga muvaffaqiyatli oshirilsa, database holati o'zgarishlarni qabul qilishi kerak. Qisqacha aytganda yoki hammasi muvaffaqiyatli kechadi yoki hech biri bajarilmaydi.

Consistency
Transaction faqat databaseni bir holatdan ikkinchisi olib o'tishni taminlaydi ya'ni databasega yoziladigan har qanday ma'lumotlar barcha belgilangan qoidalar (constraints, cascades, triggers, va boshqa)ga muvofiq ishlashi kerak. Qisqachasiga, noqonuniy ma'lumotlardan qochish imkoniyatini beradi.

Isolation
Har bir transaction operatsiyalari izolyatsiyalangan bo'lishi kerak ya'ni race condition keltirib chiqarishi kerak emas degani. Database transactionlar ketma-ket bajarilishini ta'minlash uchun row(qator)larga lock (qulf) qo'yib chiqadi. Qisqachasiga, Concurrency controlni aynan isolation bajaradi.

Durability
Transaction amalga oshirilgandan so'ng, tizim ishdan chiqgan taqdirda ham ma'lumotlar saqlanib qolishi kerak.

Real Life Example

Atomicity
Do'stingiz xisobiga 100$ o'tkazayabsiz. Jarayonlar esa: avval sizni xisobingiz tekshiriladi so'ngra xisobingizdagi summadan 100$ ayriladi va do'stingiz xisobi tekshirilib unga 100$ ni qo'shib qo'yadi. Oddiy logika )

Consistency
Sizning xisobingiz manfiyga aylanmasligi va unda yetarli mablag' bo'lishi bu qoida sifatida beriladi. Agar qoida buzilsa kompaniya minusga ishlaydi. Bunday qoidalar juda ko'p bo'lishi mumkin va men qisqacha keltirdim.

Isolation
Operatsiyalar to muavaffaqiyatli bajarilmagunigacha sizga va do'stingizga hech qanday o'zgarishlar ko'rinmasligi shart. Barcha jarayonlar isolation bo'lgan bo'lishi kerak.

Durability
O'tkazma muvaffaqiyatli kechdi endi ma'lumotlar saqlanishi va o'chib ketmasligi shart.

Transactiondan maqsad va muamolarni to'g'ri yoritib berdim deb umid qilaman.

@otabekswe

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

#interview

Intel kompaniyasi bilan bo’lgan interviewdan rejact oldim. Ammo bu ham tajriba. Ushbu postni bir kun reply qilish nasib qilsin deya shu yerga joylab qo’yayabman.

Bollar biz yutamiz!

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