1576

EN + हिं Medium

GB What is the difference between DELETE and TRUNCATE in terms of transaction log and recoverability?

IN लेन-देन लॉग और पुनर्प्राप्ति के संदर्भ में DELETE और TRUNCATE के बीच क्या अंतर है?

A

DELETE is always faster than TRUNCATE DELETE हमेशा TRUNCATE से तेज़ होता है

B

TRUNCATE cannot be rolled back in any DBMS TRUNCATE को किसी भी DBMS में वापस नहीं लाया जा सकता

C

DELETE and TRUNCATE produce identical transaction log entries DELETE और TRUNCATE समान लेनदेन लॉग प्रविष्टियाँ उत्पन्न करते हैं

D

DELETE logs each individual row deletion (fully logged) enabling row-level rollback and trigger firing; TRUNCATE uses minimal logging (deallocates entire data pages) making it much faster but in most DBMS still rollbackable within an explicit transaction पंक्ति-स्तरीय रोलबैक और ट्रिगर फायरिंग को सक्षम करने वाले प्रत्येक व्यक्तिगत पंक्ति विलोपन (पूरी तरह से लॉग) को हटाएं; TRUNCATE न्यूनतम लॉगिंग का उपयोग करता है (संपूर्ण डेटा पृष्ठों को हटा देता है) जिससे यह बहुत तेज़ हो जाता है लेकिन अधिकांश DBMS में अभी भी एक स्पष्ट लेनदेन के भीतर रोलबैक किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) DELETE: fully logged (each row deletion logged), triggers fire, WHERE clause possible, can be rolled back. TRUNCATE: minimally logged (page deallocation logged, not individual rows), no triggers, no WHERE clause, faster. In PostgreSQL and SQL Server: TRUNCATE CAN be rolled back within an explicit transaction. In MySQL: TRUNCATE always auto-commits.

व्याख्या (हिन्दी) हटाएं: पूरी तरह से लॉग किया गया (प्रत्येक पंक्ति विलोपन लॉग किया गया), आग ट्रिगर करता है, जहां क्लॉज संभव है, वापस लाया जा सकता है। ट्रंकेट: न्यूनतम रूप से लॉग किया गया (पेज डीलोकेशन लॉग किया गया, व्यक्तिगत पंक्तियाँ नहीं), कोई ट्रिगर नहीं, कोई WHERE क्लॉज नहीं, तेज़। PostgreSQL और SQL सर्वर में: TRUNCATE को एक स्पष्ट लेनदेन में वापस लाया जा सकता है। MySQL में: TRUNCATE हमेशा स्वतः-प्रतिबद्ध होता है।

1577

EN + हिं Medium

GB What is the purpose of SELECT FOR UPDATE in SQL and how does it interact with other transactions?

IN SQL में SELECT FOR UPDATE का उद्देश्य क्या है और यह अन्य लेनदेन के साथ कैसे इंटरैक्ट करता है?

A

It creates a copy of the row for update यह अद्यतन के लिए पंक्ति की एक प्रति बनाता है

B

It updates rows and returns the results यह पंक्तियों को अद्यतन करता है और परिणाम लौटाता है

C

It is identical to a regular SELECT यह नियमित चयन के समान है

D

It acquires an exclusive lock on the selected rows preventing other transactions from modifying or locking those rows until the current transaction commits or rolls back - used to implement pessimistic locking for critical operations यह चयनित पंक्तियों पर एक विशेष लॉक प्राप्त करता है जो अन्य लेनदेन को उन पंक्तियों को संशोधित या लॉक करने से रोकता है जब तक कि वर्तमान लेनदेन शुरू नहीं हो जाता है या वापस नहीं आ जाता है - इसका उपयोग महत्वपूर्ण कार्यों के लिए निराशावादी लॉकिंग को लागू करने के लिए किया जाता है।

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) SELECT FOR UPDATE: acquires X-lock (or in PostgreSQL FOR UPDATE/FOR SHARE) on selected rows. Other transactions trying to SELECT FOR UPDATE or UPDATE the same rows will block until the first transaction releases. Used for: implementing check-and-update patterns, reservation systems, inventory management. Release locks on COMMIT/ROLLBACK.

व्याख्या (हिन्दी) अद्यतन के लिए चयन करें: चयनित पंक्तियों पर एक्स-लॉक (या अद्यतन/साझा करने के लिए PostgreSQL में) प्राप्त करता है। अद्यतन के लिए चयन करने या समान पंक्तियों को अद्यतन करने का प्रयास करने वाले अन्य लेन-देन पहले लेन-देन जारी होने तक अवरुद्ध हो जाएंगे। इसके लिए उपयोग किया जाता है: चेक-एंड-अपडेट पैटर्न, आरक्षण प्रणाली, इन्वेंट्री प्रबंधन लागू करना। COMMIT/रोलबैक पर लॉक जारी करें।

1578

EN + हिं Medium

GB What happens when an INSERT violates a NOT NULL constraint vs a CHECK constraint in terms of error handling?

IN क्या होता है जब एक INSERT त्रुटि प्रबंधन के संदर्भ में NOT NULL बाधा बनाम CHECK बाधा का उल्लंघन करता है?

A

Both raise constraint violation errors but the error codes differ: NOT NULL violation raises a specific null constraint error and CHECK constraint violation raises a check constraint violation - both prevent the INSERT from completing and the transaction remains in an error state requiring rollback दोनों बाधा उल्लंघन त्रुटियों को बढ़ाते हैं लेकिन त्रुटि कोड भिन्न होते हैं: शून्य उल्लंघन एक विशिष्ट शून्य बाधा त्रुटि को जन्म देता है और चेक बाधा उल्लंघन एक चेक बाधा उल्लंघन को बढ़ाता है - दोनों INSERT को पूरा होने से रोकते हैं और लेनदेन एक त्रुटि स्थिति में रहता है जिसे रोलबैक की आवश्यकता होती है

B

CHECK constraint errors can be ignored; NOT NULL constraint errors always fail चेक बाधा त्रुटियों को नजरअंदाज किया जा सकता है; NOT NULL बाधा त्रुटियाँ हमेशा विफल रहती हैं

C

NOT NULL constraint silently replaces NULL with default value; CHECK constraint rolls back the entire transaction NOT NULL बाधा चुपचाप NULL को डिफ़ॉल्ट मान से बदल देती है; CHECK बाधा पूरे लेन-देन को वापस ले आती है

D

Both constraints produce identical errors दोनों बाधाएँ समान त्रुटियाँ उत्पन्न करती हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Both constraints prevent the INSERT and raise errors. NOT NULL violation: ORA-01400 in Oracle, ERROR 1048 in MySQL. CHECK violation: ORA-02290 in Oracle, ERROR 3819 in MySQL. Both require the transaction to be rolled back (or the statement rolled back in autocommit mode). The client must handle the error and retry or fix the data.

व्याख्या (हिन्दी) दोनों बाधाएँ INSERT को रोकती हैं और त्रुटियाँ बढ़ाती हैं। शून्य उल्लंघन नहीं: Oracle में ORA-01400, MySQL में त्रुटि 1048। उल्लंघन की जाँच करें: Oracle में ORA-02290, MySQL में त्रुटि 3819। दोनों को लेनदेन को वापस रोल करने की आवश्यकता होती है (या स्टेटमेंट को ऑटोकमिट मोड में वापस रोल किया जाता है)। क्लाइंट को त्रुटि को संभालना होगा और डेटा को पुनः प्रयास करना या ठीक करना होगा।

1579

EN + हिं Easy

GB What is the INSERT ALL statement in Oracle SQL and what problem does it solve?

IN Oracle SQL में INSERT ALL स्टेटमेंट क्या है और यह किस समस्या का समाधान करता है?

A

Inserting all rows from one table to another सभी पंक्तियों को एक तालिका से दूसरी तालिका में सम्मिलित करना

B

Oracle-specific SQL that inserts multiple rows into multiple tables in a single statement (unconditional or conditional INSERT ALL INTO t1...INTO t2...) solving the problem of making multiple table inserts atomic and efficient from a single data scan ओरेकल-विशिष्ट एसक्यूएल जो एक ही स्टेटमेंट में कई पंक्तियों को कई तालिकाओं में सम्मिलित करता है (बिना शर्त या सशर्त INSERT ALL INTO t1...INTO t2...) एकल डेटा स्कैन से एकाधिक तालिका आवेषण को परमाणु और कुशल बनाने की समस्या को हल करता है

C

Inserting all columns from a single row एक ही पंक्ति से सभी कॉलम सम्मिलित करना

D

Inserting the same row into multiple copies of a table किसी तालिका की एकाधिक प्रतियों में एक ही पंक्ति सम्मिलित करना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Oracle INSERT ALL: INSERT ALL INTO t1 (col) VALUES (val1) INTO t2 (col) VALUES (val2) SELECT 1 FROM DUAL; Or conditional: INSERT ALL WHEN id < 100 THEN INTO small_orders WHEN id >= 100 THEN INTO large_orders SELECT id, amount FROM staged_orders. Performs multiple inserts in single pass over source data, all in one atomic statement.

व्याख्या (हिन्दी) Oracle सभी सम्मिलित करें: सभी को t1 (col) मानों (val1) में t2 (col) मानों (val2) में सम्मिलित करें, दोहरे में से 1 चुनें; या सशर्त: आईडी <100 होने पर सभी को छोटे ऑर्डर में डालें, जब आईडी >= 100 हो तो बड़े ऑर्डर में डालें, चरणबद्ध ऑर्डर से आईडी, राशि चुनें। स्रोत डेटा पर एकल पास में एकाधिक प्रविष्टियाँ निष्पादित करता है, सभी एक परमाणु कथन में।

1580

EN + हिं Medium

GB What is the performance difference between NESTED LOOP JOIN HASH JOIN and SORT-MERGE JOIN?

IN नेस्टेड लूप जॉइन हैश जॉइन और सॉर्ट-मर्ज जॉइन के बीच प्रदर्शन में क्या अंतर है?

A

Nested Loop: O(n*m) good for small tables/indexed access; Hash Join: O(n+m) good for large unindexed tables (requires memory for hash table); Sort-Merge: O(n log n + m log m) good when inputs are already sorted नेस्टेड लूप: O(n*m) छोटी तालिकाओं/अनुक्रमित पहुंच के लिए अच्छा है; हैश जॉइन: O(n+m) बड़ी अनइंडेक्स्ड तालिकाओं के लिए अच्छा है (हैश तालिका के लिए मेमोरी की आवश्यकता होती है); सॉर्ट-मर्ज: O(n log n + m log m) अच्छा है जब इनपुट पहले से ही सॉर्ट किए गए हों

B

They are equally performant in all scenarios वे सभी परिदृश्यों में समान रूप से प्रदर्शन करते हैं

C

Nested Loop is always fastest नेस्टेड लूप हमेशा सबसे तेज़ होता है

D

Hash Join is always fastest हैश जॉइन हमेशा सबसे तेज़ होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Nested Loop: for each outer row, scan inner (use index). Best: small inner or indexed. Hash Join: build hash table on smaller table, probe with larger. Best: large unindexed tables. Sort-Merge: sort both, merge. Best: already-sorted inputs or when sort is needed anyway.

व्याख्या (हिन्दी) नेस्टेड लूप: प्रत्येक बाहरी पंक्ति के लिए, आंतरिक को स्कैन करें (इंडेक्स का उपयोग करें)। Best: small inner or indexed. हैश जॉइन: छोटी टेबल पर हैश टेबल बनाएं, बड़ी टेबल के साथ जांच करें। Best: large unindexed tables. Sort-Merge: sort both, merge. Best: already-sorted inputs or when sort is needed anyway.

1581

EN + हिं Easy

GB In SQL what does a FULL OUTER JOIN return?

IN एसक्यूएल में फुल आउटर जॉइन क्या लौटाता है?

A

Only matching rows from both tables दोनों तालिकाओं से केवल मेल खाने वाली पंक्तियाँ

B

All rows from BOTH tables with NULLs for non-matching sides: rows matched on both sides (complete data) unmatched rows from left table (right side NULL) and unmatched rows from right table (left side NULL) गैर-मिलान पक्षों के लिए NULL के साथ दोनों तालिकाओं की सभी पंक्तियाँ: दोनों तरफ मिलान वाली पंक्तियाँ (पूर्ण डेटा), बाईं तालिका से बेजोड़ पंक्तियाँ (दाईं ओर NULL) और दाईं तालिका से बेजोड़ पंक्तियाँ (बाईं ओर NULL)

C

All rows from the left table only सभी पंक्तियाँ केवल बाईं तालिका से

D

All rows from neither table (only NULLs) किसी भी तालिका से सभी पंक्तियाँ (केवल शून्य)

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) FULL OUTER JOIN = LEFT OUTER JOIN UNION RIGHT OUTER JOIN. Result: (1) Rows matching join condition from both tables, (2) Left-only rows with NULL right columns, (3) Right-only rows with NULL left columns. Useful for: finding unmatched records in either table.

व्याख्या (हिन्दी) पूर्ण बाहरी जोड़ = बायां बाहरी जोड़ दायां बाहरी जोड़। परिणाम: (1) दोनों तालिकाओं से जुड़ने की स्थिति से मेल खाने वाली पंक्तियाँ, (2) केवल बाएँ पंक्तियाँ शून्य दाएँ स्तंभों के साथ, (3) केवल दाएँ पंक्तियाँ शून्य बाएँ स्तंभों के साथ। इसके लिए उपयोगी: किसी भी तालिका में बेजोड़ रिकॉर्ड ढूंढना।

1582

EN + हिं Medium

GB What is the anti-join pattern and how is it implemented in SQL?

IN एंटी-जॉइन पैटर्न क्या है और इसे SQL में कैसे लागू किया जाता है?

A

A query pattern that returns rows from the left table that have NO matching rows in the right table implemented as: LEFT JOIN WHERE right.key IS NULL or NOT EXISTS (subquery) or NOT IN (subquery) एक क्वेरी पैटर्न जो बाईं तालिका से पंक्तियाँ लौटाता है, जिसमें दाहिनी तालिका में कोई मेल खाने वाली पंक्तियाँ नहीं हैं, इस प्रकार कार्यान्वित किया गया है: बाएँ शामिल हों जहाँ दाएँ.कुंजी शून्य है या मौजूद नहीं है (सबक्वेरी) या अंदर नहीं है (सबक्वेरी)

B

An outer join applied to all tables simultaneously एक बाहरी जोड़ सभी तालिकाओं पर एक साथ लागू होता है

C

A join that uses NOT EQUAL as the join condition एक जुड़ाव जो जुड़ने की शर्त के रूप में NOT EQUAL का उपयोग करता है

D

A join that reverses the join condition एक जुड़ाव जो जुड़ने की स्थिति को उलट देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Anti-join: find customers with NO orders. Method 1: SELECT c.* FROM customer c LEFT JOIN order o ON c.id=o.cust_id WHERE o.cust_id IS NULL. Method 2: NOT EXISTS subquery. Method 3: NOT IN (subquery). Performance: LEFT JOIN+NULL check or NOT EXISTS usually preferred over NOT IN when NULLs may exist.

व्याख्या (हिन्दी) एंटी-जॉइन: बिना ऑर्डर वाले ग्राहक ढूंढें। विधि 1: ग्राहक से c.* चुनें c.id=o.cust_id पर शामिल होने का आदेश छोड़ दें जहां o.cust_id शून्य है। विधि 2: सबक्वेरी मौजूद नहीं है। विधि 3: नॉट इन (सबक्वेरी)। प्रदर्शन: लेफ्ट जॉइन+न्यूल चेक या NOT EXISTS को आम तौर पर NOT IN की तुलना में प्राथमिकता दी जाती है जब NULL मौजूद हो।

1583

EN + हिं Easy

GB What is a join condition pushed down optimization and why does the optimizer do it?

IN जॉइन कंडीशन पुश डाउन ऑप्टिमाइज़ेशन क्या है और ऑप्टिमाइज़र ऐसा क्यों करता है?

A

Moving join conditions from ON to WHERE clause जुड़ने की शर्तों को ON से WHERE क्लॉज पर ले जाना

B

The query optimizer moves filtering conditions (predicates) as early as possible in the execution plan - before joining - to reduce the number of rows that need to be joined dramatically reducing the join cost क्वेरी ऑप्टिमाइज़र निष्पादन योजना में जितनी जल्दी हो सके फ़िल्टरिंग स्थितियों (विधेय) को स्थानांतरित करता है - शामिल होने से पहले - उन पंक्तियों की संख्या को कम करने के लिए जिन्हें नाटकीय रूप से शामिल करने की लागत को कम करने की आवश्यकता होती है।

C

Pushing join conditions from SQL to the application layer SQL से एप्लिकेशन लेयर पर जुड़ने की शर्तों को पुश करना

D

Moving join conditions from WHERE to HAVING जुड़ने की स्थिति को WHERE से HAVING की ओर ले जाना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Predicate pushdown: instead of joining 1M rows then filtering, filter first (e.g., WHERE status=active) reducing to 10K rows, then join those. The optimizer rewrites the logical plan to apply filters before joins. Critical for performance, especially in distributed/columnar databases.

व्याख्या (हिन्दी) पुशडाउन की भविष्यवाणी करें: 1M पंक्तियों को जोड़ने और फिर फ़िल्टर करने के बजाय, पहले फ़िल्टर करें (उदाहरण के लिए, WHERE स्थिति=सक्रिय) 10K पंक्तियों तक कम करें, फिर उनमें शामिल हों। ऑप्टिमाइज़र जुड़ने से पहले फ़िल्टर लागू करने की तार्किक योजना को फिर से लिखता है। प्रदर्शन के लिए महत्वपूर्ण, विशेष रूप से वितरित/स्तंभकार डेटाबेस में।

1584

EN + हिं Medium

GB What causes a Cartesian product to accidentally occur in SQL and how is it detected?

IN SQL में कार्टेशियन उत्पाद के आकस्मिक रूप से उत्पन्न होने का क्या कारण है और इसका पता कैसे लगाया जाता है?

A

Using a FROM clause with multiple tables without specifying join conditions or using CROSS JOIN - detected by the absence of WHERE/ON conditions between tables and the result set size = product of table sizes जुड़ने की शर्तों को निर्दिष्ट किए बिना या क्रॉस जॉइन का उपयोग किए बिना कई तालिकाओं के साथ FROM क्लॉज का उपयोग करना - तालिकाओं और परिणाम सेट आकार के बीच WHERE/ON शर्तों की अनुपस्थिति से पता लगाया गया = तालिका आकार का उत्पाद

B

Using aggregate functions on joined tables सम्मिलित तालिकाओं पर समग्र कार्यों का उपयोग करना

C

Using INNER JOIN without ON clause ON क्लॉज के बिना INNER JOIN का उपयोग करना

D

Using outer joins incorrectly बाहरी जोड़ का गलत तरीके से उपयोग करना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Accidental Cartesian: SELECT * FROM orders, customers (missing WHERE orders.cust_id=customers.id) produces orders times customers rows. Detected by: result row count = n times m (massive), EXPLAIN shows CROSS JOIN or no join condition. Always verify FROM clause joins when using comma-separated table list.

व्याख्या (हिन्दी) आकस्मिक कार्टेशियन: ऑर्डर से चुनें *, ग्राहक (जहां ऑर्डर.cust_id=customers.id गायब है) ग्राहकों की पंक्तियों से गुणा ऑर्डर उत्पन्न करता है। द्वारा पता लगाया गया: परिणाम पंक्ति गणना = n गुना m (विशाल), EXPLAIN क्रॉस जॉइन या कोई जॉइन स्थिति नहीं दिखाता है। अल्पविराम से अलग की गई तालिका सूची का उपयोग करते समय हमेशा FROM क्लॉज जॉइन को सत्यापित करें।

1585

EN + हिं Easy

GB What is a non-equi join (theta join with non-equality condition) and give a practical example?

IN नॉन-इक्विटी जॉइन (थीटा जॉइन विद नॉन-इक्वलिटी कंडीशन) क्या है और एक व्यावहारिक उदाहरण दें?

A

A join using comparison operators other than equality (>, <, >=, <=, BETWEEN, LIKE) in the join condition - e.g. joining employee salary to a salary_grade table where salary BETWEEN grade_low AND grade_high समानता के अलावा अन्य तुलना ऑपरेटरों का उपयोग करते हुए एक जुड़ाव (>, =,

B

A join that returns NULL values only एक जुड़ाव जो केवल NULL मान लौटाता है

C

A join that does not work correctly ऐसा जुड़ाव जो ठीक से काम नहीं करता

D

A join between tables with different schemas विभिन्न स्कीमा वाली तालिकाओं के बीच एक जुड़ाव

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Non-equi join: SELECT e.name, g.grade FROM employee e JOIN salary_grade g ON e.salary BETWEEN g.low AND g.high. Other examples: self join for triangular queries, joining date ranges, finding records within a distance threshold. Cannot use hash join (hash works only with equi-conditions).

व्याख्या (हिन्दी) नॉन-इक्वी जॉइन: कर्मचारी से ई.नाम, जी.ग्रेड चुनें और जी.कम और जी.उच्च के बीच ई.वेतन पर वेतन_ग्रेड जी में शामिल हों। अन्य उदाहरण: त्रिकोणीय प्रश्नों के लिए स्वयं शामिल होना, दिनांक सीमाओं को जोड़ना, दूरी सीमा के भीतर रिकॉर्ड ढूंढना। हैश जॉइन का उपयोग नहीं किया जा सकता (हैश केवल सम-स्थितियों के साथ काम करता है)।

1586

EN + हिं Easy

GB What is the lateral join (or CROSS JOIN LATERAL) in SQL and what problem does it solve?

IN SQL में लेटरल जॉइन (या CROSS JOIN LATERAL) क्या है और यह किस समस्या का समाधान करता है?

A

A join between geographically distributed databases भौगोलिक रूप से वितरित डेटाबेस के बीच एक जुड़ाव

B

A join that only works with parallel query execution एक जुड़ाव जो केवल समानांतर क्वेरी निष्पादन के साथ काम करता है

C

A join that works sideways (column to column) एक जोड़ जो बग़ल में काम करता है (कॉलम से कॉलम)

D

A join where the right side (subquery or function) can reference columns from tables to its left in the FROM clause - allowing correlation within the FROM clause useful for top-N per group queries एक जुड़ाव जहां दाईं ओर (सबक्वेरी या फ़ंक्शन) FROM क्लॉज में तालिकाओं से बाईं ओर के कॉलम को संदर्भित कर सकता है - FROM क्लॉज के भीतर सहसंबंध की अनुमति देता है जो प्रति समूह प्रश्नों के लिए शीर्ष-एन के लिए उपयोगी है।

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) LATERAL: SELECT c.id, top_orders.* FROM customers c JOIN LATERAL (SELECT * FROM orders WHERE cust_id=c.id ORDER BY total DESC LIMIT 3) AS top_orders ON true. References c.id from outer FROM. Solves: top-N per group, unnesting arrays, calling row-returning functions with per-row arguments.

व्याख्या (हिन्दी) लेटरल: सी.आईडी, टॉप_ऑर्डर का चयन करें। * ग्राहकों से सी जॉइन लैटरल (चुनें * उन ऑर्डरों से जहां cust_id=c.id ऑर्डर कुल DESC सीमा 3 के अनुसार) टॉप_ऑर्डर के रूप में सत्य पर। बाहरी FROM से संदर्भ c.id. Solves: top-N per group, unnesting arrays, calling row-returning functions with per-row arguments.

1587

EN + हिं Easy

GB What is the join order problem in query optimization and why does it matter for performance?

IN क्वेरी ऑप्टिमाइज़ेशन में जॉइन ऑर्डर समस्या क्या है और यह प्रदर्शन के लिए क्यों मायने रखती है?

A

The order in which columns are listed in ON clause वह क्रम जिसमें कॉलम ON क्लॉज में सूचीबद्ध हैं

B

The order of joins in different user queries विभिन्न उपयोगकर्ता प्रश्नों में जुड़ने का क्रम

C

The alphabetical order of table names in FROM clause FROM खंड में तालिका नामों का वर्णमाला क्रम

D

The optimal sequence in which to join multiple tables; join order is critical because different orders produce dramatically different intermediate result set sizes and the optimizer must find the order minimizing total data processed एकाधिक तालिकाओं को जोड़ने का इष्टतम क्रम; जॉइन ऑर्डर महत्वपूर्ण है क्योंकि अलग-अलग ऑर्डर नाटकीय रूप से अलग-अलग मध्यवर्ती परिणाम सेट आकार उत्पन्न करते हैं और ऑप्टिमाइज़र को संसाधित किए गए कुल डेटा को कम करने वाला ऑर्डर ढूंढना होगा

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Join order optimization: with n tables, there are n!/2 possible join orders. A bad order (joining two large tables first) creates huge intermediates. Optimal order (smallest results first) minimizes I/O. Optimizers use dynamic programming or heuristics (join smaller tables first, use indexed joins first).

व्याख्या (हिन्दी) ज्वाइन ऑर्डर ऑप्टिमाइज़ेशन: n तालिकाओं के साथ, n!/2 संभावित ज्वाइन ऑर्डर हैं। एक ख़राब क्रम (पहले दो बड़ी तालिकाओं को जोड़ना) विशाल मध्यवर्ती बनाता है। इष्टतम क्रम (सबसे छोटे परिणाम पहले) I/O को न्यूनतम करता है। ऑप्टिमाइज़र डायनेमिक प्रोग्रामिंग या ह्यूरिस्टिक्स का उपयोग करते हैं (पहले छोटी तालिकाओं में शामिल हों, पहले अनुक्रमित जॉइन का उपयोग करें)।

1588

EN + हिं Medium

GB What is the difference between ON and USING clauses in JOIN syntax?

IN JOIN सिंटैक्स में ON और USING क्लॉज के बीच क्या अंतर है?

A

USING is for outer joins; ON is for inner joins USING बाहरी जुड़ावों के लिए है; ON आंतरिक जुड़ाव के लिए है

B

ON: allows any join condition including different column names (ON a.dept_id = b.id); USING: shorthand for equality join on same-named columns in both tables (USING(dept_id)) - eliminates duplicate columns in result चालू: विभिन्न कॉलम नामों सहित किसी भी जुड़ने की स्थिति की अनुमति देता है (ON a.dept_id = b.id); उपयोग करना: समानता के लिए आशुलिपि दोनों तालिकाओं में समान-नाम वाले कॉलमों को जोड़ती है (USING(dept_id)) - परिणाम में डुप्लिकेट कॉलम को समाप्त करता है

C

USING works with non-equality conditions; ON does not USING गैर-समानता स्थितियों के साथ काम करता है; चालू नहीं है

D

They produce different results वे भिन्न-भिन्न परिणाम उत्पन्न करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) ON: flexible, any condition, explicit, allows different column names, both columns appear in SELECT *. USING(col): implicit equality on same-named column, result has only one copy of that column in SELECT *. NATURAL JOIN: automatic USING on all common columns (risky if schema changes).

व्याख्या (हिन्दी) चालू: लचीला, कोई भी शर्त, स्पष्ट, अलग-अलग कॉलम नामों की अनुमति देता है, दोनों कॉलम SELECT * में दिखाई देते हैं। उपयोग (कॉल): समान नाम वाले कॉलम पर अंतर्निहित समानता, परिणाम में SELECT * में उस कॉलम की केवल एक प्रति है। प्राकृतिक जुड़ाव: सभी सामान्य स्तंभों पर स्वचालित उपयोग (यदि स्कीमा बदलता है तो जोखिम भरा)।

1589

EN + हिं Easy

GB What is semi-join reduction in distributed query optimization?

IN वितरित क्वेरी अनुकूलन में सेमी-ज्वाइन रिडक्शन क्या है?

A

Semi-join as a replacement for anti-join एंटी-जॉइन के प्रतिस्थापन के रूप में सेमी-जॉइन

B

Using semi-joins to reduce data transferred in distributed joins वितरित जॉइन में स्थानांतरित डेटा को कम करने के लिए सेमी-जॉइन का उपयोग करना

C

A technique to reduce the number of join conditions जुड़ने की स्थितियों की संख्या को कम करने की एक तकनीक

D

A technique to reduce data transfer in distributed joins: instead of shipping all of relation R to the site of relation S first compute the semi-join S semi-join R (much smaller) ship that to R site compute the join there - reduces network traffic डिस्ट्रीब्यूटेड जॉइन में डेटा ट्रांसफर को कम करने की एक तकनीक: सभी रिलेशन R को रिलेशन S की साइट पर भेजने के बजाय पहले सेमी-जॉइन S सेमी-जॉइन R (बहुत छोटा) शिप की गणना करें जिसे R साइट पर भेजें, वहां जॉइन की गणना करें - नेटवर्क ट्रैफ़िक को कम करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Distributed semi-join reduction: (1) At S site: project S onto join attributes -> Sj (small). (2) Ship Sj to R site. (3) At R site: filter R to only rows with matches (R semi-join Sj = Rr). (4) Ship Rr back to S site. (5) Compute final join. Effective when join attribute projection is much smaller than full relation.

व्याख्या (हिन्दी) वितरित सेमी-जॉइन रिडक्शन: (1) एस साइट पर: प्रोजेक्ट एस ऑन जॉइन एट्रिब्यूट्स -> एसजे (छोटा)। (2) एसजे को आर साइट पर शिप करें। (3) आर साइट पर: आर को केवल मिलान वाली पंक्तियों में फ़िल्टर करें (आर सेमी-जॉइन एसजे = आरआर)। (4) आरआर को एस साइट पर वापस भेजें। (5) अंतिम जुड़ाव की गणना करें। प्रभावी तब होता है जब सम्मिलित विशेषता प्रक्षेपण पूर्ण संबंध से बहुत छोटा होता है।

1590

EN + हिं Easy

GB What is the bushy join tree vs left-deep join tree distinction in query optimization?

IN क्वेरी अनुकूलन में झाड़ीदार जुड़ाव वृक्ष बनाम बाएँ-गहरे जुड़ाव वृक्ष के बीच क्या अंतर है?

A

Left-deep: each inner side of a join is a base table (chain structure: ((A join B) join C) join D) - allows pipelining but limited join orders; Bushy: inner sides can be intermediate results ((A join B) join (C join D)) - more join orders can exploit parallelism लेफ्ट-डीप: जॉइन का प्रत्येक आंतरिक पक्ष एक आधार तालिका है (श्रृंखला संरचना: ((ए जॉइन बी) जॉइन सी) जॉइन डी) - पाइपलाइनिंग की अनुमति देता है लेकिन सीमित जॉइन ऑर्डर; जंगली: आंतरिक पक्ष मध्यवर्ती परिणाम हो सकते हैं ((ए जुड़ते हैं बी) जुड़ते हैं (सी जुड़ते हैं डी)) - अधिक जुड़ने वाले आदेश समानता का फायदा उठा सकते हैं

B

A classification of table shapes not join orders तालिका आकृतियों का वर्गीकरण आदेशों में शामिल नहीं होता है

C

Bushy trees are less efficient than left-deep trees झाड़ीदार पेड़ बाएं-गहरे पेड़ों की तुलना में कम कुशल होते हैं

D

They are different names for the same join structure वे एक ही जुड़ाव संरचना के लिए अलग-अलग नाम हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Left-deep trees: enable pipeline execution (outer always a base table, inner always indexed - use nested-loop index join efficiently). Search space: O(n!). Bushy trees: allow any join order, enable parallel branches, larger search space O(2^n * n!). Most optimizers consider left-deep or zigzag trees for efficiency.

व्याख्या (हिन्दी) बाएं-गहरे पेड़: पाइपलाइन निष्पादन सक्षम करें (बाहरी हमेशा एक आधार तालिका, आंतरिक हमेशा अनुक्रमित - नेस्टेड-लूप इंडेक्स जॉइन का कुशलतापूर्वक उपयोग करें)। खोज स्थान: O(n!). जंगली पेड़: किसी भी जुड़ाव आदेश की अनुमति दें, समानांतर शाखाओं को सक्षम करें, बड़ा खोज स्थान O(2^n * n!)। अधिकांश अनुकूलक दक्षता के लिए बाएं-गहरे या टेढ़े-मेढ़े पेड़ों पर विचार करते हैं।

DBMS — MCQ Practice