مرکزی مواد پر جائیں
ماڈیول 10 · سبق 3 از 4کورس میں 39/57~12 min
ماڈیول اسباق (3/4)

جامع اور جزوی اشاریہ جات

پچھلے اسباق میں ہم نے لکیری DBMS سوالات (WHERE country = 'Italy') کے لیے اشاریہ جات کا استعمال کرتے ہوئے احاطہ کیا۔ جب ہم دو مشترکہ محاذوں پر تلاش کرتے ہیں تو کیا ہوگا؟

مثال کے طور پر، ایک حقیقی ای کامرس میں ہم ایسے آرڈرز تلاش کرنا چاہتے ہیں جو مخصوص کسٹمر ID AND سے تعلق رکھتے ہوں جو ایک مقررہ وقت کی حد میں آتے ہیں: WHERE customer_id = 90 AND placed_at >= '2025-01-01'

اگر آپ کے پاس صرف customer_id پر ایک بنیادی اشاریہ ہے، تو Postgres کو بائنری ٹری کا استعمال کرتے ہوئے کسٹمر کے 50 آرڈرز مل جائیں گے، لیکن پھر اسے ان تمام 50 کے ذریعے دستی طور پر اور ترتیب وار، سستی سے تاریخوں کو آنکھ سے فلٹر کرنا ہوگا۔

جامع اشاریہ جات

ہم DBMS سے کہہ سکتے ہیں کہ "تجزیاتی لغت" فائلوں کو کسی ایک کلیدی جہت کے ساتھ نہیں بلکہ متعدد کے ساتھ ترتیب دیں۔

SQL
CREATE INDEX idx_orders_customer_date ON orders(customer_id, placed_at);

ایک "جامع" انڈیکس اپنے پیرامیٹرز کی ترتیب کو بہت اہم سمجھتا ہے: یہاں B-Tree نوڈس گروپ کرتا ہے اور customer_id کو بلاک میں سختی سے درجہ بندی کرتا ہے (علیحدگی کے لیے سب سے زیادہ امتیازی سلوک)؛ ان کے اندر ذیلی درخت مختلف placed_at وقت کی قدروں کے ساتھ بالکل ترتیب شدہ ترتیب میں رہتے ہیں۔

یہ ڈھانچہ بے دردی سے WHERE شقوں کو متعدد نیسٹڈ پیشین گوئیوں کے ساتھ فنا کر دیتا ہے۔

جزوی اشاریہ جات (فلٹر شدہ اشاریہ جات)

ہر انڈیکس صارف کے ان پٹ اسٹریمز پر ڈسک کی جگہ اور CPU کی قیمت لگاتا ہے۔ کیا ہوگا اگر ای کامرس کو فلٹر کو مسلسل چھانٹنے اور بازیافت کرنے کی ضرورت ہو، لیکن صرف ریکارڈ کی ایک اقلیت کے لیے؟ (مثال کے طور پر: بغیر پڑھے ہوئے-اطلاعات کی جانچ کو تیزی سے پولنگ کرنا۔) تمام 10,000,000 اطلاعات پر "is_read" انڈیکس بنانا ناقابل یقین حد تک تکلیف دہ ہے اگر "Unread" ان میں سے صرف 5 کی نمائندگی کرتا ہے۔

SQL
CREATE INDEX idx_unread_notifs ON notifications(user_id)
  WHERE is_read = false; -- Questa aggiuntiva è l'"Indice Parziale"

ڈیٹا بیس بجلی کی تیز رفتار B-Tree بنائے گا جو DB تک فوری رسائی کی چابیاں محفوظ کرتا ہے صرف اگر ریکارڈ بغیر پڑھا ہوا ہو! ڈسک 10 ملین کے ساتھ ایک کی بجائے 5 قطاروں (3 بائٹس) کے انڈیکس سے پیار کرے گی۔ فاسٹ SELECTs کا مکمل فائدہ:

SELECT * FROM notifications WHERE user_id = 2 AND is_read = false;

آپ کی باری

ورزش#sql.m10.l3.e1
کوششیں: 0لوڈ ہو رہا ہے…

ہم عارضی پاس ورڈز / ری سیٹ ٹوکنز کی تلاش کو بہتر بنانا چاہتے ہیں۔ ہم بہت کثرت سے SELECT کالز کرتے ہیں جو کسی مخصوص ملک سے سائن اپ کیے گئے تمام کسٹمرز کو تلاش کرتے ہوئے ایک مشہور شہر کے ساتھ مل کر کرتے ہیں۔\n'کسٹمرز' پر 'idx_cust_loc' کے نام سے ایک جامع انڈیکس بنائیں۔ پہلے 'ملک' فیلڈ (جو زیادہ مخصوص ہے) اور پھر 'شہر' فیلڈ سے گزریں۔

ایڈیٹر لوڈ ہو رہا ہے…
اشارہ دکھائیں۔

نحو: ٹیبل پر انڈیکس کا نام بنائیں (col1, col2)؛

3 کوششوں کے بعد حل دستیاب ہے۔

مشروط (جزوی) اشاریہ جات کی تلاش

ورزش#sql.m10.l3.e2
کوششیں: 0لوڈ ہو رہا ہے…

خریداری کے صارف کی تلاش کو بہتر بنائیں: صارفین پہلے سے اندراج کرتے ہیں لیکن ہمیں صرف ان کو ان کے تاریخی سائن اپ آرڈر میں درج کرنے کی ضرورت ہے ('کسٹمرز' میں 'signed_up_on' پر ایک انڈیکس بنائیں) لیکن صرف مکمل اسٹرنگ 'شہر': 'Milano' کے صارفین کے لیے محدود۔

ایڈیٹر لوڈ ہو رہا ہے…
اشارہ دکھائیں۔

اس کا اعلان عام طور پر ٹارگٹ پراپرٹی پر کیا جاتا ہے۔ آخر میں آپ جادوئی کلیدی لفظ WHERE city = 'Milano' شامل کرتے ہیں۔

3 کوششوں کے بعد حل دستیاب ہے۔