"غیر ضروری لیکن مطلوبہ کام" سے پیدا ہونے والے SQL کارکردگی کے مسائل

مضمون کو سمجھنے کے لیے درکار علم کی سطح: ڈیٹا بیس اور ایس کیو ایل کی عمومی تفہیم، DBMS کے ساتھ کچھ عملی تجربہ۔ ممکنہ طور پر سب سے اہم چیز جو آپ موثر SQL سوالات لکھنا سیکھ سکتے ہیں وہ ہے اشاریہ سازی۔ تاہم، دوسری جگہ، بہت پیچھے، یہ علم ہے کہ بہت سے SQL کلائنٹس کو ڈیٹا بیس کی ضرورت ہوتی ہے کہ وہ بہت زیادہ "غیر ضروری لیکن ضروری کام" کریں ۔ میرے بعد کہو: "غیر ضروری لیکن واجب کام" کیا ہے؟ جیسا کہ کیپٹن اوبیویس ہمیں بتاتا ہے، وہ:

غیر ضروری

ہمارے کلائنٹ کی درخواست کو درج ذیل ڈیٹا کی ضرورت ہے: کچھ بھی غیر معمولی نہیں۔ ہم ایک مووی ڈیٹا بیس (جیسے سکیلا ڈیٹا بیس ) کے ساتھ کام کر رہے ہیں اور صارفین کو تمام فلموں کا ٹائٹل اور درجہ بندی دکھانا چاہتے ہیں۔ درج ذیل استفسار وہ نتیجہ دے سکتا ہے جس کی ہمیں ضرورت ہے:

SELECT title, rating
FROM film

تاہم، ہماری درخواست (یا ہمارا ORM) اس سوال پر عمل درآمد کرتی ہے:

SELECT *
FROM film

اس کے نتیجے میں ہمیں کیا ملتا ہے؟ اندازہ لگائیں۔ ہمیں بہت سی بیکار معلومات ملتی ہیں: دائیں طرف آپ یہاں تک کہ کچھ پیچیدہ JSON کو لوڈ ہوتے دیکھ سکتے ہیں:

• ڈسک سے
• کیش کرنے کے لئے
• تار سے
• کلائنٹ کی یاد میں
• اور آخر میں پھینک دیا [غیر ضروری طور پر]

ہاں، ہم اس میں سے زیادہ تر معلومات کو پھینک دیتے ہیں۔ اس معلومات کو نکالنے کے لیے کیے گئے تمام اقدامات مکمل طور پر بیکار نکلے۔ یہ سچ ہے؟ یہ سچ ہے.

لازمی

اور اب - بدترین حصہ. اگرچہ اصلاح کار اب بہت کچھ کر سکتے ہیں، لیکن ڈیٹا بیس کے لیے یہ اعمال لازمی ہیں۔ ڈیٹا بیس کے پاس یہ جاننے کا کوئی طریقہ نہیں ہے کہ کلائنٹ ایپلی کیشن کو اس ڈیٹا کے 95% کی ضرورت نہیں ہے۔ اور یہ سب سے آسان مثال ہے۔ کئی ٹیبلز کو جوڑنے کا تصور کریں... تو کیا، آپ کہتے ہیں، لیکن ڈیٹا بیس تیز ہیں؟ آئیے میں آپ کو کچھ ایسی چیزوں کے بارے میں آگاہ کرتا ہوں جن کے بارے میں آپ نے شاید سوچا بھی نہ ہو۔ بلاشبہ، انفرادی درخواست پر عمل درآمد کا وقت واقعی کسی بھی چیز کو متاثر نہیں کرتا ہے۔ ٹھیک ہے، یہ ڈیڑھ گنا سست چلا، لیکن ہم اس سے گزریں گے، ٹھیک ہے؟ سہولت کے لئے؟ کبھی کبھی یہ سچ ہوتا ہے۔ لیکن اگر آپ ہمیشہ سہولت کے لیے کارکردگی کو قربان کرتے ہیں تو یہ چھوٹی چھوٹی چیزیں شامل ہونا شروع ہو جائیں گی۔ اب ہم کارکردگی (انفرادی درخواستوں پر عمل درآمد کی رفتار) کے بارے میں بات نہیں کریں گے، بلکہ تھرو پٹ (سسٹم رسپانس ٹائم) کے بارے میں بات کریں گے، اور پھر سنگین مسائل شروع ہوں گے، جنہیں حل کرنا اتنا آسان نہیں ہے۔ اس وقت جب آپ اسکیل ایبلٹی کھو دیتے ہیں۔ آئیے عملدرآمد کے منصوبوں پر ایک نظر ڈالتے ہیں، اس معاملے میں، اوریکل ڈی بی ایم ایس:

--------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes |
--------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 |   166K|
|   1 |  TABLE ACCESS FULL| FILM |  1000 |   166K|
--------------------------------------------------

کےساتھ موازنا:

--------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes |
--------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 | 20000 |
|   1 |  TABLE ACCESS FULL| FILM |  1000 | 20000 |
--------------------------------------------------

SELECT عنوان کے بجائے SELECT * استفسار چلانے سے، درجہ بندی ڈیٹا بیس میں 8 گنا زیادہ میموری استعمال کرتی ہے۔ کچھ بھی غیر متوقع نہیں، ٹھیک ہے؟ ہم جانتے تھے کہ ایسا ہوگا۔ لیکن ہم پھر بھی اپنی بہت سی درخواستوں کے لیے اس سے اتفاق کرتے ہیں جن میں ہمیں اس تمام ڈیٹا کی ضرورت نہیں ہے۔ ہم ڈیٹابیس کے لیے غیر ضروری لیکن لازمی کام بناتے ہیں ، جو ڈھیر اور ڈھیر ہوتا رہتا ہے۔ ہم ضرورت سے 8 گنا زیادہ میموری استعمال کرتے ہیں (ضرور بدل جائے گا)۔ دریں اثنا، دیگر تمام مراحل میں (ڈسک I/O، نیٹ ورک پر ڈیٹا کی منتقلی، کلائنٹ کی طرف سے میموری کی کھپت) مسائل بالکل ایک جیسے ہیں، لیکن میں ان کو چھوڑ دوں گا اور اس کے بجائے دیکھوں گا...

اشاریہ جات کا استعمال

آج زیادہ تر ڈیٹا بیس پہلے ہی انڈیکس کو کور کرنے کے تصور کی تعریف کر چکے ہیں ۔ کورنگ انڈیکس بذات خود ایک خاص قسم کا انڈیکس نہیں ہے۔ لیکن یہ کسی خاص استفسار کے لیے ایک "خصوصی اشاریہ" بن سکتا ہے، یا تو "حادثے سے" یا اس لیے کہ ایسا ہونا مقصود تھا۔ درج ذیل استفسار پر غور کریں:

SELECT *
FROM actor
WHERE last_name LIKE 'A%'

اس کے نفاذ کے معاملے میں کچھ بھی غیر متوقع نہیں ہے۔ یہ ایک سادہ سی درخواست ہے۔ انڈیکس کے لحاظ سے رینج دیکھیں، ٹیبل تک رسائی حاصل کریں - اور آپ کا کام ہو گیا:

-------------------------------------------------------------------
| Id  | Operation                   | Name                | Rows  |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                     |     8 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ACTOR               |     8 |
|*  2 |   INDEX RANGE SCAN          | IDX_ACTOR_LAST_NAME |     8 |
-------------------------------------------------------------------

اچھا منصوبہ ہے، ہے نا؟ ٹھیک ہے، اگر ہمیں واقعی اس کی ضرورت ہے، تو نہیں: ظاہر ہے، ہم میموری وغیرہ کو ضائع کر رہے ہیں۔ آئیے اس سوال کو ایک متبادل کے طور پر دیکھتے ہیں:

SELECT first_name, last_name
FROM actor
WHERE last_name LIKE 'A%'

اس کا منصوبہ یہ ہے:

----------------------------------------------------
| Id  | Operation        | Name            | Rows  |
----------------------------------------------------
|   0 | SELECT STATEMENT |                 |     8 |
|*  1 |  INDEX RANGE SCAN| IDX_ACTOR_NAMES |     8 |
----------------------------------------------------

ہم میز تک رسائی کو مکمل طور پر ختم کرنے میں کامیاب ہو گئے، ایک انڈیکس کی موجودگی کی بدولت جو ہماری استفسار کی تمام ضروریات کو پورا کرتا ہے... ایک کورنگ انڈیکس۔ کیا یہ اہم ہے؟ اور کیسے! یہ نقطہ نظر آپ کو طول و عرض کے آرڈر کے ذریعہ کچھ سوالات کو تیز کرنے کی اجازت دیتا ہے (یا جب کچھ تبدیلیوں کے بعد انڈیکس مزید احاطہ نہیں کرتا ہے تو شدت کے حکم سے انہیں کم کر دیتا ہے)۔ کورنگ انڈیکس ہمیشہ استعمال نہیں کیا جا سکتا۔ آپ کو اشاریہ جات کے لیے ادائیگی کرنی ہوگی اور آپ کو ان میں زیادہ اضافہ نہیں کرنا چاہیے۔ لیکن اس معاملے میں، سب کچھ واضح ہے. آئیے کارکردگی کا جائزہ لیتے ہیں:

SET SERVEROUTPUT ON
DECLARE
  v_ts TIMESTAMP;
  v_repeat CONSTANT NUMBER := 100000;
BEGIN
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Наихудший вариант requestа: перерасход памяти ПЛЮС доступ к таблице
      SELECT *
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Оператор 1 : ' || (SYSTIMESTAMP - v_ts));
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Улучшенный request, но все равно с доступом к таблице
      SELECT /*+INDEX(actor(last_name))*/
        first_name, last_name
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Оператор 2 : ' || (SYSTIMESTAMP - v_ts));
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Оптимальный request: покрывающий индекс
      SELECT /*+INDEX(actor(last_name, first_name))*/
        first_name, last_name
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Оператор 3 : ' || (SYSTIMESTAMP - v_ts));
END;
/

نوٹ کریں کہ ایکٹر ٹیبل میں صرف 4 کالم ہوتے ہیں، لہٰذا اسٹیٹمنٹ 1 اور 2 کے درمیان کارکردگی کا فرق اتنا بڑا نہیں ہے، لیکن یہ اب بھی اہم ہے۔ میں یہ بھی نوٹ کروں گا کہ میں نے اوریکل آپٹیمائزر کے اشارے استعمال کیے ہیں تاکہ آپٹیمائزر کو استفسار کے لیے ایک یا دوسرے مخصوص انڈیکس کا انتخاب کرے۔ آپریٹر 3 ہماری دوڑ کا غیر متنازعہ فاتح ہے۔ اس کی کارکردگی بہت بہتر ہے، اور ہم ایک انتہائی سادہ سوال کے بارے میں بات کر رہے ہیں۔ ایک بار پھر، جب ہم SELECT * لکھتے ہیں، تو ہم ڈیٹا بیس کے لیے غیر ضروری لیکن لازمی کام بناتے ہیں جسے وہ آپٹمائز نہیں کر سکتا۔ وہ کورنگ انڈیکس کا انتخاب نہیں کرے گی کیونکہ اس میں اس کے منتخب کردہ LAST_NAME انڈیکس سے تھوڑا زیادہ اوور ہیڈ ہے، اور، دوسری چیزوں کے علاوہ، اسے اب بھی ایک بیکار LAST_UPDATE کالم کو بازیافت کرنے کے لیے ٹیبل تک رسائی حاصل کرنی ہوگی، مثال کے طور پر۔ لیکن ہم SELECT* کا جتنا گہرائی سے تجزیہ کرتے ہیں، چیزیں اتنی ہی خراب ہوتی ہیں۔ آؤ اس پر بات کریں...

ایس کیو ایل تبادلے۔

Optimizers اتنی اچھی کارکردگی کا مظاہرہ کرتے ہیں کیونکہ وہ SQL سوالات کو تبدیل کرتے ہیں ( میں نے اس بارے میں بات کی تھی کہ یہ کس طرح کام کرتا ہے اپنی حالیہ گفتگو میں Voxxed Days in Zurich )۔ مثال کے طور پر، ایک انتہائی طاقتور "استثنیٰ JOIN" تبدیلی ہے۔ مندرجہ ذیل مددگار نقطہ نظر پر غور کریں جو ہمیں ہر بار دستی طور پر ان تمام ٹیبلز میں شامل ہونے سے بچنے کے لیے بنانا پڑتا تھا۔

CREATE VIEW v_customer AS
SELECT
  c.first_name, c.last_name,
  a.address, ci.city, co.country
FROM customer c
JOIN address a USING (address_id)
JOIN city ci USING (city_id)
JOIN country co USING (country_id)

یہ نظریہ گاہک کے کسٹمر ٹیبل اور ان کے پتے کے حصوں کے لیے مختلف جدولوں کے درمیان تمام "...- سے-ایک" کو جوڑتا ہے۔ آپ کا شکریہ، نارملائزیشن۔ تصور کریں کہ، اس نقطہ نظر کے ساتھ تھوڑا سا کام کرنے کے بعد، ہم اس کے عادی ہو گئے اور اس کے نیچے موجود میزوں کو بھول گئے۔ اور اب ہم درج ذیل استفسار پر عمل کرتے ہیں:

SELECT *
FROM v_customer

نتیجے کے طور پر، ہمیں ایک بہت ہی متاثر کن منصوبہ ملتا ہے:

----------------------------------------------------------------
| Id  | Operation            | Name     | Rows  | Bytes | Cost |
----------------------------------------------------------------
|   0 | SELECT STATEMENT     |          |   599 | 47920 |   14 |
|*  1 |  HASH JOIN           |          |   599 | 47920 |   14 |
|   2 |   TABLE ACCESS FULL  | COUNTRY  |   109 |  1526 |    2 |
|*  3 |   HASH JOIN          |          |   599 | 39534 |   11 |
|   4 |    TABLE ACCESS FULL | CITY     |   600 | 10800 |    3 |
|*  5 |    HASH JOIN         |          |   599 | 28752 |    8 |
|   6 |     TABLE ACCESS FULL| CUSTOMER |   599 | 11381 |    4 |
|   7 |     TABLE ACCESS FULL| ADDRESS  |   603 | 17487 |    3 |
----------------------------------------------------------------

جی بلکل. ڈیٹا بیس یہ تمام جوائنز اور مکمل ٹیبل اسکین کر رہا ہے کیونکہ ہم نے اسے کرنے کو کہا تھا - یہ تمام ڈیٹا حاصل کریں۔ اب، ایک بار پھر، تصور کریں کہ ہمیں واقعی اس کی ضرورت تھی: کیا، سنجیدگی سے، ٹھیک ہے؟ اب آپ کو سمجھ آنے لگی ہے کہ میں کیا کہہ رہا ہوں۔ لیکن تصور کریں کہ ہم نے ماضی کی غلطیوں سے کچھ سیکھا ہے، اور اس پر عمل درآمد کریں، زیادہ بہترین سوال:

SELECT first_name, last_name
FROM v_customer

اب دیکھتے ہیں کیا ہوا!

------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost  |
------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |   599 | 16173 |     4 |
|   1 |  NESTED LOOPS      |             |   599 | 16173 |     4 |
|   2 |   TABLE ACCESS FULL| CUSTOMER    |   599 | 11381 |     4 |
|*  3 |   INDEX UNIQUE SCAN| SYS_C007120 |     1 |     8 |     0 |
------------------------------------------------------------------

پھانسی کے معاملے میں بہتر کے لیے زبردست تبدیلیاں۔ جوائنز کو ختم کر دیا گیا ہے کیونکہ آپٹمائزر اب دیکھ سکتا ہے کہ وہ بیکار ہیں ، اور اگر یہ دیکھ سکتا ہے کہ (اور آپ نے * کو منتخب کر کے اس کام کو لازمی نہیں بنایا ہے)، تو یہ صرف یہ سب کام نہیں کر سکتا۔ اس معاملے میں ایسا کیوں ہے؟ غیر ملکی کلید CUSTOMER.ADDRESS_ID پرائمری کلید ADDRESS.ADDRESS_ID میں بعد کی بالکل ایک قدر کی ضمانت دیتا ہے، جس کا مطلب ہے کہ JOIN آپریشن "...-to-one" جوائن ہوگا جو قطاروں کی تعداد میں اضافہ یا کمی نہیں کرتا ہے۔ . اور چونکہ ہم کسی بھی قطار کا انتخاب یا درخواست نہیں کرتے ہیں، اس لیے انہیں لوڈ کرنے کا کوئی فائدہ نہیں ہے۔ JOIN کو ہٹانے سے شاید استفسار کے نتیجے پر کوئی اثر نہیں پڑے گا۔ ڈیٹا بیس ہر وقت ایسا کرتے ہیں۔ آپ درج ذیل استفسار کو تقریباً کسی بھی ڈیٹا بیس پر چلا سکتے ہیں۔

-- Oracle
SELECT CASE WHEN EXISTS (
  SELECT 1 / 0 FROM dual
) THEN 1 ELSE 0 END
FROM dual

-- Более адекватные диалекты SQL, например, PostgreSQL
SELECT EXISTS (SELECT 1 / 0)

اس صورت میں، آپ توقع کر سکتے ہیں کہ ریاضی کے استثناء کو پھینک دیا جائے، جیسا کہ درج ذیل استفسار پر عمل کرتے وقت:

SELECT 1 / 0 FROM dual

لیکن ایسا نہیں ہوتا۔ اصلاح کنندہ (یا یہاں تک کہ تجزیہ کار) اس بات کو یقینی بنا سکتا ہے کہ EXISTS predicate (SELECT ..) میں کوئی بھی منتخب فہرست عناصر استفسار کے نتیجے کو تبدیل نہیں کرے گا، اس لیے اسے انجام دینے کی ضرورت نہیں ہے۔ اس طرح!

اسی دوران...

ORMs کے ساتھ سب سے زیادہ پریشان کن مسائل میں سے ایک یہ ہے کہ وہ SELECT * سوالات لکھنے میں بہت آسان ہیں۔ درحقیقت، مثال کے طور پر، HQL/JPQL میں وہ عام طور پر بطور ڈیفالٹ استعمال ہوتے ہیں۔ ہم SELECT شق کو مکمل طور پر چھوڑ سکتے ہیں، کیونکہ ہم پوری ہستی کو بازیافت کرنے جا رہے ہیں، ٹھیک ہے؟ مثال کے طور پر:

FROM v_customer

مثال کے طور پر، Vlad Mihalcea، ایک ماہر اور Hibernate کے ساتھ تیار کرنے کے وکیل ، تجویز کرتے ہیں کہ تقریباً ہمیشہ جب آپ کو یقین ہو کہ آپ چیک آؤٹ کے بعد کوئی تبدیلی محفوظ نہیں کرنا چاہتے ہیں تو [کوالیفائیڈ] سوالات استعمال کریں۔ ORMs آبجیکٹ گرافس کے استقامت کے مسئلے کے حل میں بہت زیادہ سہولت فراہم کرتے ہیں۔ نوٹ: استقامت۔ اصل میں آبجیکٹ گراف میں ترمیم کرنے اور تبدیلیوں کو بچانے کے کام آپس میں جڑے ہوئے ہیں۔ لیکن اگر آپ ایسا نہیں کرنے جا رہے ہیں، تو پھر جوہر نکالنے کی زحمت کیوں؟ ایک درخواست کیوں نہیں لکھتے؟ آئیے واضح کریں: کارکردگی کے نقطہ نظر سے، خاص طور پر آپ کے مخصوص استعمال کے معاملے کے مطابق استفسار لکھنا کسی دوسرے آپشن سے واضح طور پر بہتر ہے۔ آپ کو اس کی پرواہ نہیں ہوسکتی ہے کیونکہ آپ کا ڈیٹا سیٹ چھوٹا ہے اور اس سے کوئی فرق نہیں پڑتا ہے۔ زبردست. لیکن جب آپ کو آخرکار اسکیل ایبلٹی کی ضرورت ہو تو، ہستی کے گراف کو لازمی عبور کرنے کے بجائے استفسارات کو استعمال کرنے کے لیے اپنی ایپلی کیشنز کو دوبارہ ڈیزائن کرنا کافی مشکل ہوگا۔ اور آپ کو اس کے بغیر کچھ کرنا پڑے گا۔

یہ معلوم کرنے کے لیے کہ آیا کچھ موجود ہے قطاریں گننا

وسائل کے بدترین ضیاع میں سے ایک یہ ہے کہ COUNT(*) سوالات صرف یہ دیکھنے کے لیے چلا رہے ہیں کہ آیا ڈیٹا بیس میں کچھ ہے یا نہیں۔ مثال کے طور پر، ہمیں یہ معلوم کرنے کی ضرورت ہے کہ آیا دیے گئے صارف کے پاس بالکل بھی آرڈر ہیں۔ اور ہم درخواست پر عمل کرتے ہیں:

SELECT count(*)
FROM orders
WHERE user_id = :user_id

ابتدائی۔ اگر COUNT = 0، تو کوئی آرڈر نہیں ہے۔ ورنہ، ہاں۔ کارکردگی اتنی بری نہیں ہوگی کیونکہ ہمارے پاس ORDERS.USER_ID کالم پر ایک انڈیکس ہے۔ لیکن آپ کے خیال میں مندرجہ بالا استفسار کی کارکردگی کا موازنہ درج ذیل آپشن سے کیا جائے گا:

-- Oracle
SELECT CASE WHEN EXISTS (
  SELECT *
  FROM orders
  WHERE user_id = :user_id
) THEN 1 ELSE 0 END
FROM dual

-- Более адекватные диалекты SQL, например, PostgreSQL
SELECT EXISTS (
  SELECT *
  FROM orders
  WHERE user_id = :user_id
)

یہ معلوم کرنے کے لیے کسی راکٹ سائنسدان کی ضرورت نہیں ہے کہ ایک حقیقی وجود کی پیشین گوئی جیسے ہی اسے پہلی تار مل جائے گی اضافی تاروں کی تلاش بند کر دے گی ۔ لہذا اگر نتیجہ "کوئی آرڈر نہیں" نکلا، تو رفتار کا موازنہ کیا جائے گا۔ اگر، تاہم، نتیجہ "ہاں، آرڈرز ہیں"، تو ایسی صورت میں جہاں صحیح مقدار کو شمار کرنے کی ضرورت نہیں ہے، جواب بہت تیزی سے موصول ہوگا۔ سب کے بعد، ہم صحیح تعداد میں دلچسپی نہیں رکھتے ہیں. تاہم، ہم نے ڈیٹابیس سے کہا کہ اس کا حساب لگائیں ( غیر ضروری کام ) اور ڈیٹا بیس کو یہ معلوم نہیں ہے کہ ہم 1 ( ضروری کام ) سے زیادہ کے تمام نتائج کو نظر انداز کر رہے ہیں۔ بلاشبہ، یہ بہت برا ہوگا اگر ہم اسی نتائج کو حاصل کرنے کے لیے JPA کی حمایت یافتہ کلیکشن پر list.size() کو کال کریں۔ میں نے پہلے ہی اپنے بلاگ پر اس کے بارے میں پہلے ہی لکھا تھا، اور اس پر دونوں اختیارات کی تقابلی جانچ کی تھی۔

نتیجہ

یہ مضمون واضح بیان کرتا ہے۔ ڈیٹا بیس کو غیر ضروری لیکن مطلوبہ کام کرنے پر مجبور نہ کریں ۔ یہ غیر ضروری ہے کیونکہ، ضروریات کو دیکھتے ہوئے، آپ جانتے ہیں کہ کچھ مخصوص کام کرنے کی ضرورت نہیں ہے۔ تاہم، آپ ڈیٹا بیس کو ایسا کرنے کو کہتے ہیں۔ اس کی ضرورت ہے کیونکہ ڈیٹا بیس کے پاس اس بات کو یقینی بنانے کا کوئی طریقہ نہیں ہے کہ یہ کام غیر ضروری ہے ۔ یہ معلومات صرف کلائنٹ کے لیے دستیاب ہے اور سرور کے لیے دستیاب نہیں ہے۔ لہذا ڈیٹا بیس کو اس پر عمل کرنا ہوگا۔ مضمون SELECT * پر توجہ مرکوز کرتا ہے، بنیادی طور پر اس وجہ سے کہ یہ دیکھنے کے لئے ایک آسان چیز ہے۔ لیکن یہ نہ صرف ڈیٹا بیس پر لاگو ہوتا ہے۔ یہ تمام تقسیم شدہ الگورتھم پر لاگو ہوتا ہے جس میں کلائنٹ سرور کو غیر ضروری لیکن مطلوبہ کام کرنے کو کہتا ہے ۔ آپ کی اوسط AngularJS ایپلیکیشن میں کتنے N+1 ٹاسک ہیں جہاں UI سروس A کے نتیجے میں، سروس B کو متعدد بار کال کرنے کی بجائے، B کو تمام کالوں کو ایک ہی کال میں پیک کرنے کے بجائے لوپ کرتا ہے؟ یہ ایک بہت عام رجحان ہے۔ حل ہمیشہ ایک ہی ہوتا ہے۔ آپ اپنے حکموں پر عمل درآمد کرنے والی ہستی کو جتنی زیادہ معلومات فراہم کرتے ہیں، اتنی ہی تیزی سے (نظریاتی طور پر) ان احکامات پر عمل درآمد کرتا ہے۔ بہترین سوالات لکھیں۔ ہمیشہ آپ کا پورا نظام اس کے لیے آپ کا شکریہ ادا کرے گا۔ اصل آرٹیکل