DBMS — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 2982 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2982 questions
1591
EN + हिं Medium
GB What is join selectivity and how does it affect query optimization?
IN सम्मिलित चयनात्मकता क्या है और यह क्वेरी अनुकूलन को कैसे प्रभावित करती है?
A
The number of join conditions in a query किसी क्वेरी में शामिल होने की शर्तों की संख्या
B
The number of tables that can be joined simultaneously एक साथ जोड़ी जा सकने वाली तालिकाओं की संख्या
C
The speed of different join algorithms विभिन्न जॉइन एल्गोरिदम की गति
D
The fraction of rows in the cross product that actually match the join condition (result_rows / (|R| times |S|)); low selectivity (few matches) is better; optimizer uses statistics to estimate selectivity and choose between join methods क्रॉस उत्पाद में पंक्तियों का अंश जो वास्तव में जुड़ने की स्थिति से मेल खाता है (result_rows / (|R| बार |S|)); कम चयनात्मकता (कुछ मिलान) बेहतर है; ऑप्टिमाइज़र चयनात्मकता का अनुमान लगाने और जुड़ने के तरीकों के बीच चयन करने के लिए आंकड़ों का उपयोग करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Join selectivity = |R join S| / (|R| times |S|). Close to 0: few matches (selective), small result. Close to 1: most rows match (non-selective), large result. Estimated using column statistics (distinct values, histograms). Optimizer multiplies selectivities across predicates to estimate result size and choose join order/method.
व्याख्या (हिन्दी) चयनात्मकता से जुड़ें = |R, S से जुड़ें| / (|आर| गुना |एस|)। 0 के करीब: कुछ मिलान (चयनात्मक), छोटा परिणाम। 1 के करीब: अधिकांश पंक्तियाँ मेल खाती हैं (गैर-चयनात्मक), बड़ा परिणाम। स्तंभ आँकड़ों (विशिष्ट मान, हिस्टोग्राम) का उपयोग करके अनुमान लगाया गया। ऑप्टिमाइज़र परिणाम आकार का अनुमान लगाने और शामिल होने का क्रम/विधि चुनने के लिए विधेय में चयनात्मकता को गुणा करता है।
1592
EN + हिं Easy
GB What is the index nested loop join and what conditions make it efficient?
IN इंडेक्स नेस्टेड लूप जॉइन क्या है और कौन सी स्थितियाँ इसे कुशल बनाती हैं?
A
A join algorithm that processes loops in parallel एक जॉइन एल्गोरिदम जो लूप को समानांतर में संसाधित करता है
B
An index join that works only with primary keys एक इंडेक्स जॉइन जो केवल प्राथमिक कुंजी के साथ काम करता है
C
A nested loop join that creates indexes during execution एक नेस्टेड लूप जॉइन जो निष्पादन के दौरान इंडेक्स बनाता है
D
A join where for each row in the outer table the DBMS uses an index on the inner tables join key to directly look up matching rows - efficient when: outer table is small inner table has an appropriate index on the join column and join selectivity is low एक ऐसा जुड़ाव जहां बाहरी तालिका में प्रत्येक पंक्ति के लिए डीबीएमएस आंतरिक तालिकाओं पर एक इंडेक्स का उपयोग करता है, सीधे मेल खाने वाली पंक्तियों को देखने के लिए कुंजी जोड़ता है - कुशल जब: बाहरी तालिका छोटी होती है, आंतरिक तालिका में शामिल होने वाले कॉलम पर एक उपयुक्त सूचकांक होता है और जुड़ने की चयनात्मकता कम होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Index NL join: for each outer row -> index lookup on inner table (O(log n) or O(1) for hash index). Total cost: |outer| times (index lookup cost). Efficient when outer is small (few lookups needed) and inner has index. Much better than full inner scan per outer row.
व्याख्या (हिन्दी) इंडेक्स एनएल जॉइन: प्रत्येक बाहरी पंक्ति के लिए -> आंतरिक तालिका पर इंडेक्स लुकअप (हैश इंडेक्स के लिए ओ (लॉग एन) या ओ (1)। कुल लागत: |बाहरी| समय (सूचकांक लुकअप लागत)। जब बाहरी छोटा होता है (कुछ लुकअप की आवश्यकता होती है) और आंतरिक में सूचकांक होता है तो कुशल होता है। प्रति बाहरी पंक्ति के पूर्ण आंतरिक स्कैन से कहीं बेहतर।
1593
EN + हिं Easy
GB What is join elimination in query optimization?
IN क्वेरी ऑप्टिमाइज़ेशन में कनेक्ट एलिमिनेशन क्या है?
A
Removing joins that return no results उन जोड़ों को हटाना जिनसे कोई परिणाम नहीं मिलता
B
Removing unnecessary joins identified by the optimizer ऑप्टिमाइज़र द्वारा पहचाने गए अनावश्यक जोड़ों को हटाना
C
Eliminating one table from a join एक जॉइन से एक टेबल को हटाना
D
When the query optimizer removes a JOIN from the execution plan because it can prove the join does not affect the result (typically: joining to a unique FK parent table when only the child columns are selected) reducing unnecessary I/O जब क्वेरी ऑप्टिमाइज़र निष्पादन योजना से एक JOIN को हटा देता है क्योंकि यह साबित कर सकता है कि जुड़ाव परिणाम को प्रभावित नहीं करता है (आमतौर पर: जब केवल चाइल्ड कॉलम चुने जाते हैं तो एक अद्वितीय FK पैरेंट तालिका में शामिल होना) अनावश्यक I/O को कम करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Join elimination: if you SELECT only columns from table A and JOIN table B on FK(A.b_id)=B.id where B.id is UNIQUE, and SELECT no B columns, the join is provably unnecessary (cannot filter A rows or produce duplicates). Optimizer removes the join to B entirely, reducing I/O dramatically.
व्याख्या (हिन्दी) उन्मूलन में शामिल हों: यदि आप तालिका ए से केवल कॉलम चुनते हैं और एफके (ए.बी_आईडी) = बी.आईडी पर तालिका बी में शामिल होते हैं जहां बी.आईडी अद्वितीय है, और कोई बी कॉलम नहीं चुनते हैं, तो जुड़ाव अनावश्यक साबित होता है (ए पंक्तियों को फ़िल्टर नहीं कर सकता या डुप्लिकेट उत्पन्न नहीं कर सकता)। ऑप्टिमाइज़र I/O को नाटकीय रूप से कम करते हुए, B से जुड़ाव को पूरी तरह से हटा देता है।
1594
EN + हिं Medium
GB How does SQL handle duplicate rows when joining tables with repeated foreign key values?
IN बार-बार विदेशी कुंजी मानों वाली तालिकाओं में शामिल होने पर SQL डुप्लिकेट पंक्तियों को कैसे संभालता है?
A
Each matching combination of rows produces a row in the result - if table A has 3 rows with dept_id=5 and table B has 2 rows with id=5 the join produces 3 times 2=6 rows for dept_id=5 (multiplicative not additive) पंक्तियों का प्रत्येक मिलान संयोजन परिणाम में एक पंक्ति उत्पन्न करता है - यदि तालिका A में dept_id=5 के साथ 3 पंक्तियाँ हैं और तालिका B में id=5 के साथ 2 पंक्तियाँ हैं, तो जुड़ने से dept_id=5 के लिए 3 गुना 2=6 पंक्तियाँ उत्पन्न होती हैं (गुणक योगात्मक नहीं)
B
Duplicates are automatically removed डुप्लिकेट स्वचालित रूप से हटा दिए जाते हैं
C
Duplicates from the same table are removed but not across tables एक ही तालिका से डुप्लिकेट हटा दिए जाते हैं लेकिन सभी तालिकाओं से नहीं
D
Only the first matching pair is included in the result परिणाम में केवल पहली मिलान जोड़ी को शामिल किया गया है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Join cardinality multiplication: for each row in A with join key k, and each row in B with key k, one result row is produced. If A has m rows and B has n rows with key k, the join produces m times n rows for that key value. This is why M:N joins without aggregation produce large result sets.
व्याख्या (हिन्दी) कार्डिनैलिटी गुणन में शामिल हों: कुंजी k के साथ A में प्रत्येक पंक्ति के लिए, और कुंजी k के साथ B में प्रत्येक पंक्ति के लिए, एक परिणाम पंक्ति उत्पन्न होती है। यदि A में m पंक्तियाँ हैं और B में कुंजी k के साथ n पंक्तियाँ हैं, तो जुड़ाव उस कुंजी मान के लिए m गुना n पंक्तियाँ उत्पन्न करता है। यही कारण है कि M:N एकत्रीकरण के बिना जुड़ने से बड़े परिणाम सेट उत्पन्न होते हैं।
1595
EN + हिं Easy
GB What is star join query optimization in data warehouse systems?
IN डेटा वेयरहाउस सिस्टम में स्टार जॉइन क्वेरी ऑप्टिमाइज़ेशन क्या है?
A
An optimization for queries against star schemas: filter dimension tables first (highly selective) then use bitmap indexes to intersect the fact table rows matching ALL dimension filters avoiding full fact table scans स्टार स्कीमा के विरुद्ध प्रश्नों के लिए एक अनुकूलन: पहले आयाम तालिकाओं को फ़िल्टर करें (अत्यधिक चयनात्मक) फिर पूर्ण तथ्य तालिका स्कैन से बचने के लिए सभी आयाम फ़िल्टर से मेल खाने वाली तथ्य तालिका पंक्तियों को काटने के लिए बिटमैप इंडेक्स का उपयोग करें
B
A join that requires star schema data model एक जुड़ाव जिसके लिए स्टार स्कीमा डेटा मॉडल की आवश्यकता होती है
C
Joining star schema tables inefficiently स्टार स्कीमा तालिकाओं को अकुशलतापूर्वक जोड़ना
D
A join between multiple fact tables एकाधिक तथ्य तालिकाओं के बीच एक जुड़ाव
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Star join optimization: (1) Apply each dimension filter separately on fact table using bitmap index. (2) AND the bitmaps together (bit intersection). (3) Only retrieve matching fact table rows. Extremely efficient for typical OLAP queries that filter on multiple dimension attributes.
व्याख्या (हिन्दी) स्टार जॉइन ऑप्टिमाइज़ेशन: (1) बिटमैप इंडेक्स का उपयोग करके तथ्य तालिका पर प्रत्येक आयाम फ़िल्टर को अलग से लागू करें। (2) और बिटमैप एक साथ (बिट प्रतिच्छेदन)। (3) केवल मेल खाने वाली तथ्य तालिका पंक्तियाँ ही पुनः प्राप्त करें। विशिष्ट OLAP क्वेरीज़ के लिए अत्यधिक कुशल जो एकाधिक आयाम विशेषताओं पर फ़िल्टर करती हैं।
1596
EN + हिं Medium
GB What is the grace hash join algorithm and how does it handle tables larger than available memory?
IN ग्रेस हैश जॉइन एल्गोरिदम क्या है और यह उपलब्ध मेमोरी से बड़ी तालिकाओं को कैसे संभालता है?
A
A hash join that uses grace period before executing एक हैश जॉइन जो निष्पादित करने से पहले अनुग्रह अवधि का उपयोग करता है
B
A hash join variant that partitions BOTH relations into buckets based on hash of join key (partitioning phase) then independently hash-joins matching partition pairs that fit in memory (probing phase) - handles relations larger than RAM by avoiding the need to hold everything in memory at once एक हैश जॉइन वैरिएंट, जो जॉइन कुंजी (विभाजन चरण) के हैश के आधार पर दोनों संबंधों को बकेट में विभाजित करता है, फिर स्वतंत्र रूप से मेमोरी में फिट होने वाले विभाजन जोड़े से मेल खाता हैश-जॉइन करता है (जांच चरण) - एक ही बार में मेमोरी में सब कुछ रखने की आवश्यकता से बचकर रैम से बड़े संबंधों को संभालता है
C
An optimization for hash joins on indexed columns अनुक्रमित स्तंभों पर हैश जुड़ने के लिए एक अनुकूलन
D
A hash join variant for distributed databases वितरित डेटाबेस के लिए एक हैश जॉइन वैरिएंट
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Grace hash join: (1) Partition phase: hash both R and S on join key into k buckets (R1..Rk and S1..Sk). Matching rows hash to same bucket. (2) Build/probe phase: for each i, load Ri into hash table (fits in memory), probe with Si. Total I/O: 3(|R|+|S|) page reads/writes. Handles data larger than memory.
व्याख्या (हिन्दी) ग्रेस हैश जॉइन: (1) विभाजन चरण: जॉइन कुंजी पर आर और एस दोनों को के बकेट (आर1..आरके और एस1..एसके) में हैश करें। पंक्तियों का हैश एक ही बकेट से मेल खाता है। (2) निर्माण/जांच चरण: प्रत्येक i के लिए, Ri को हैश तालिका में लोड करें (मेमोरी में फिट बैठता है), Si के साथ जांच करें। कुल I/O: 3(|R|+|S|) पृष्ठ पढ़ता/लिखता है। मेमोरी से बड़े डेटा को संभालता है।
1597
EN + हिं Medium
GB What happens to join performance when joining on columns with very low cardinality?
IN बहुत कम कार्डिनैलिटी वाले कॉलम पर जुड़ने पर प्रदर्शन में क्या होता है?
A
Low cardinality only affects sort-merge joins कम कार्डिनैलिटी केवल सॉर्ट-मर्ज जॉइन को प्रभावित करती है
B
Low cardinality always improves join performance कम कार्डिनैलिटी हमेशा जुड़ाव प्रदर्शन में सुधार करती है
C
Low cardinality join columns have poor index selectivity (index not beneficial for equality joins - will return many rows) cause data skew in hash joins (one bucket overloaded) and may require special handling like bitmap indexes or skew-aware hash distribution कम कार्डिनैलिटी जॉइन कॉलम में खराब इंडेक्स चयनात्मकता होती है (समानता जॉइन के लिए इंडेक्स फायदेमंद नहीं है - कई पंक्तियां लौटाएगा) हैश जॉइन में डेटा स्कू का कारण बनता है (एक बाल्टी अतिभारित) और बिटमैप इंडेक्स या स्क्यू-अवेयर हैश वितरण जैसे विशेष हैंडलिंग की आवश्यकता हो सकती है
D
Low cardinality is ideal for hash joins हैश जॉइन के लिए कम कार्डिनैलिटी आदर्श है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Low cardinality problems: (1) B-tree index useless for equality on low-cardinality column (full scan faster). (2) Hash join skew: status=active bucket gets most rows, causing memory overflow. Solutions: bitmap indexes (great for low cardinality OLAP), skew handling (separate processing for hot key values).
व्याख्या (हिन्दी) कम कार्डिनैलिटी समस्याएं: (1) बी-ट्री इंडेक्स कम-कार्डिनैलिटी कॉलम पर समानता के लिए बेकार है (पूर्ण स्कैन तेजी से)। (2) हैश जॉइन स्क्यू: स्थिति=सक्रिय बकेट को अधिकांश पंक्तियाँ मिलती हैं, जिससे मेमोरी ओवरफ्लो हो जाती है। समाधान: बिटमैप इंडेक्स (कम कार्डिनैलिटी ओएलएपी के लिए बढ़िया), स्क्यू हैंडलिंग (हॉट कुंजी मानों के लिए अलग प्रसंस्करण)।
1598
EN + हिं Medium
GB What is the SQL:1999 NATURAL JOIN and why is it considered risky in production code?
IN SQL:1999 नेचुरल जॉइन क्या है और इसे उत्पादन कोड में जोखिम भरा क्यों माना जाता है?
A
A join optimized for natural data patterns प्राकृतिक डेटा पैटर्न के लिए अनुकूलित एक जुड़ाव
B
A join that requires no database knowledge एक ऐसा जुड़ाव जिसके लिए किसी डेटाबेस ज्ञान की आवश्यकता नहीं है
C
A join that works on natural language conditions एक जुड़ाव जो प्राकृतिक भाषा स्थितियों पर काम करता है
D
Automatically joins on ALL columns with the same name in both tables using equality without requiring explicit ON clause - risky because schema changes (adding a new column with same name in both tables) silently change join semantics स्पष्ट ON क्लॉज की आवश्यकता के बिना समानता का उपयोग करते हुए दोनों तालिकाओं में समान नाम वाले सभी कॉलमों पर स्वचालित रूप से जुड़ जाता है - जोखिम भरा है क्योंकि स्कीमा बदलता है (दोनों तालिकाओं में समान नाम के साथ एक नया कॉलम जोड़ना) चुपचाप जॉइन सिमेंटिक्स को बदल देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) NATURAL JOIN risks: (1) Implicitly joins on ALL matching column names - if you add a column with same name to both tables, the join condition silently changes. (2) Hard to understand without knowing schemas. (3) Breaks when column names change. Always prefer explicit ON or USING clauses in production.
व्याख्या (हिन्दी) स्वाभाविक जुड़ाव जोखिम: (1) सभी मेल खाने वाले कॉलम नामों पर अंतर्निहित रूप से जुड़ता है - यदि आप दोनों तालिकाओं में समान नाम वाला कॉलम जोड़ते हैं, तो जुड़ने की स्थिति चुपचाप बदल जाती है। (2) स्कीमा को जाने बिना समझना कठिन है। (3) कॉलम नाम बदलने पर टूट जाता है। उत्पादन में हमेशा स्पष्ट ON या USING क्लॉज को प्राथमिकता दें।
1599
EN + हिं Medium
GB What is the probe side and build side terminology in hash join and how does the optimizer decide which table is which?
IN हैश जॉइन में जांच पक्ष और बिल्ड साइड शब्दावली क्या है और ऑप्टिमाइज़र कैसे तय करता है कि कौन सी तालिका कौन सी है?
A
The build side is the left table; probe is always the right बिल्ड साइड बाईं ओर की टेबल है; जांच हमेशा सही होती है
B
Build side is always the outer table बिल्ड साइड हमेशा बाहरी टेबल होती है
C
Build side: the SMALLER relation - loaded entirely into hash table in memory. Probe side: the LARGER relation - each row is used to probe the hash table. Optimizer assigns smaller relation as build side to minimize memory requirements निर्माण पक्ष: छोटा संबंध - पूरी तरह से मेमोरी में हैश तालिका में लोड किया गया। जांच पक्ष: बड़ा संबंध - प्रत्येक पंक्ति का उपयोग हैश तालिका की जांच के लिए किया जाता है। मेमोरी आवश्यकताओं को कम करने के लिए ऑप्टिमाइज़र बिल्ड साइड के रूप में छोटे संबंध निर्दिष्ट करता है
D
The optimizer always chooses randomly अनुकूलक हमेशा यादृच्छिक रूप से चयन करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hash join phases: Build: iterate over smaller relation (build side), compute hash(join_key), store in hash table. Probe: iterate over larger relation (probe side), compute hash(join_key), look up in hash table for matches. Smaller table as build side fits hash table in memory, avoiding grace hash join overhead.
व्याख्या (हिन्दी) हैश जुड़ने के चरण: बिल्ड: छोटे संबंध (बिल्ड साइड) पर पुनरावृत्त करें, हैश (join_key) की गणना करें, हैश तालिका में स्टोर करें। जांच: बड़े संबंध (जांच पक्ष) पर पुनरावृत्ति करें, हैश (join_key) की गणना करें, मिलान के लिए हैश तालिका में देखें। बिल्ड साइड के रूप में छोटी टेबल मेमोरी में हैश टेबल को फिट करती है, ग्रेस हैश जॉइन ओवरहेड से बचती है।
1600
EN + हिं Easy
GB What does RIGHT OUTER JOIN return and is there a preferred alternative?
IN राइट आउटर जॉइन क्या लौटाता है और क्या कोई पसंदीदा विकल्प है?
A
All rows from the right table plus non-matching left table rows दाहिनी तालिका की सभी पंक्तियाँ और बाईं तालिका की गैर-मिलान पंक्तियाँ
B
Only rows where the right table has NULL values केवल वे पंक्तियाँ जहाँ दाएँ तालिका में NULL मान हैं
C
All rows from RIGHT table (with NULLs for unmatched left side) and only matching rows from LEFT table - functionally equivalent to reversing table order and using LEFT OUTER JOIN (which is more readable and universally preferred) दाएँ तालिका से सभी पंक्तियाँ (बेजोड़ बाईं ओर के लिए NULL के साथ) और बाईं तालिका से केवल मेल खाने वाली पंक्तियाँ - कार्यात्मक रूप से तालिका क्रम को उलटने और LEFT OUTER JOIN का उपयोग करने के बराबर (जो अधिक पठनीय और सार्वभौमिक रूप से पसंदीदा है)
D
All rows from both tables दोनों तालिकाओं से सभी पंक्तियाँ
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RIGHT JOIN (A, B) = LEFT JOIN (B, A) with reversed table order. Since LEFT JOIN is more natural (read left-to-right: I want all of the left table), most developers avoid RIGHT JOIN and simply reorder the tables to use LEFT JOIN. Results are identical; its a code readability convention.
व्याख्या (हिन्दी) दाएं जोड़ (ए, बी) = बाएं जोड़ (बी, ए) उलटे तालिका क्रम के साथ। चूंकि लेफ्ट जॉइन अधिक प्राकृतिक है (बाएं से दाएं पढ़ें: मुझे बाईं तालिका की सभी चीजें चाहिए), अधिकांश डेवलपर्स राइट जॉइन से बचते हैं और लेफ्ट जॉइन का उपयोग करने के लिए तालिकाओं को फिर से व्यवस्थित करते हैं। परिणाम समान हैं; यह एक कोड पठनीयता सम्मेलन है।
1601
EN + हिं Easy
GB In query optimization what is join reordering with cross-product avoidance and why must the optimizer avoid cross-products?
IN क्वेरी ऑप्टिमाइज़ेशन में क्रॉस-प्रोडक्ट अवॉइडेंस के साथ जॉइन रीऑर्डरिंग क्या है और ऑप्टिमाइज़र को क्रॉस-प्रोडक्ट्स से क्यों बचना चाहिए?
A
Avoiding the use of Cartesian product notation कार्टेशियन उत्पाद संकेतन के उपयोग से बचना
B
The optimizer ensures that cross products (joins with no condition between two tables) are avoided or placed last in the join tree since they produce n times m rows with no filtering - immediately followed by a filter is converted to a join ऑप्टिमाइज़र यह सुनिश्चित करता है कि क्रॉस उत्पाद (दो तालिकाओं के बीच बिना किसी शर्त के जुड़ते हैं) को टाला जाता है या ज्वाइन ट्री में अंतिम स्थान पर रखा जाता है क्योंकि वे बिना किसी फ़िल्टरिंग के n गुना m पंक्तियों का उत्पादन करते हैं - इसके तुरंत बाद एक फ़िल्टर को एक जोड़ में बदल दिया जाता है
C
Reordering joins to be in alphabetical order पुनः क्रमित करना वर्णानुक्रम में जुड़ना है
D
Removing all cross products from query plans क्वेरी योजनाओं से सभी क्रॉस उत्पादों को हटाना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Optimizer cross-product avoidance: in a WHERE clause, identify join conditions between tables. Group tables that have direct join conditions together. Tables with no direct join conditions connected via a cross product - optimizer delays this until after other joins have reduced row counts. Cross product early = catastrophic performance.
व्याख्या (हिन्दी) ऑप्टिमाइज़र क्रॉस-प्रोडक्ट परिहार: WHERE क्लॉज में, तालिकाओं के बीच जुड़ने की स्थिति की पहचान करें। समूह तालिकाएँ जिनमें एक साथ सीधे जुड़ने की स्थितियाँ होती हैं। क्रॉस उत्पाद के माध्यम से जुड़े बिना किसी प्रत्यक्ष जुड़ाव की स्थिति वाली तालिकाएँ - ऑप्टिमाइज़र इसमें तब तक देरी करता है जब तक कि अन्य जुड़ने से पंक्ति की संख्या कम नहीं हो जाती। क्रॉस उत्पाद जल्दी = विनाशकारी प्रदर्शन।
1602
EN + हिं Medium
GB What is the difference between INNER JOIN and WHERE clause joins (implicit join syntax)?
IN इनर जॉइन और व्हेयर क्लॉज जॉइन (अंतर्निहित जॉइन सिंटैक्स) के बीच क्या अंतर है?
A
INNER JOIN cannot be used with aggregate functions इनर जॉइन का उपयोग समग्र कार्यों के साथ नहीं किया जा सकता है
B
They are semantically identical in standard SQL - both produce the same result; but INNER JOIN (explicit syntax) is preferred because it clearly separates join conditions from filter conditions making code more readable and maintainable वे मानक SQL में शब्दार्थ की दृष्टि से समान हैं - दोनों समान परिणाम देते हैं; लेकिन इनर जॉइन (स्पष्ट वाक्यविन्यास) को प्राथमिकता दी जाती है क्योंकि यह स्पष्ट रूप से जॉइन शर्तों को फ़िल्टर स्थितियों से अलग करता है जिससे कोड अधिक पठनीय और रखरखाव योग्य हो जाता है
C
WHERE clause joins are faster than INNER JOIN जहां क्लॉज जॉइन इनर जॉइन से तेज होते हैं
D
WHERE clause joins support outer joins; INNER JOIN does not जहां खंड जुड़ता है, बाहरी जुड़ाव का समर्थन करता है; इनर जॉइन नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Implicit join: SELECT * FROM A, B WHERE A.id = B.a_id AND B.status = active. Explicit join: SELECT * FROM A INNER JOIN B ON A.id = B.a_id WHERE B.status = active. Both produce identical results. Explicit preferred because: separates join conditions (ON) from filter conditions (WHERE), clearer intent, required for outer joins.
व्याख्या (हिन्दी) अंतर्निहित जुड़ाव: A, B से * चुनें जहां A.id = B.a_id और B.status = सक्रिय है। स्पष्ट जुड़ाव: चुनें * ए इनर जॉइन बी से ए.आईडी = बी.ए_आईडी पर जहां बी.स्टेटस = सक्रिय। दोनों समान परिणाम देते हैं। स्पष्ट को प्राथमिकता दी जाती है क्योंकि: जुड़ने की स्थिति (ON) को फ़िल्टर की स्थिति (WHERE) से अलग करता है, स्पष्ट इरादा, बाहरी जुड़ाव के लिए आवश्यक है।
1603
EN + हिं Easy
GB What is the merge join (sort-merge join) algorithm and under what conditions is it most efficient?
IN मर्ज जॉइन (सॉर्ट-मर्ज जॉइन) एल्गोरिदम क्या है और यह किन परिस्थितियों में सबसे कुशल है?
A
A join that merges two tables into one एक जोड़ जो दो तालिकाओं को एक में मिला देता है
B
A join algorithm that merges indexes एक जॉइन एल्गोरिदम जो इंडेक्स को मर्ज करता है
C
A join that only works when tables have the same number of rows एक जुड़ाव जो केवल तभी काम करता है जब तालिकाओं में पंक्तियों की संख्या समान हो
D
A join algorithm that sorts both input relations on the join attribute then merges them in a single linear scan; most efficient when: both inputs are already sorted on the join attribute or when sorting is needed anyway (the sort cost is amortized) or when the join result is large एक जॉइन एल्गोरिदम जो जॉइन विशेषता पर दोनों इनपुट संबंधों को सॉर्ट करता है और फिर उन्हें एक एकल रैखिक स्कैन में विलय कर देता है; सबसे कुशल तब जब: दोनों इनपुट पहले से ही जॉइन विशेषता पर सॉर्ट किए गए हों या जब सॉर्टिंग की वैसे भी आवश्यकता हो (सॉर्ट लागत परिशोधित हो) या जब जॉइन परिणाम बड़ा हो
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Sort-merge join: (1) Sort R and S on join attribute (O(n log n + m log m)). (2) Merge: linearly scan both sorted relations simultaneously matching join keys (O(n+m)). Total: O(n log n + m log m). Most efficient: when inputs are pre-sorted (clustered index), when join is on primary key, or when result is large (hash join memory pressure).
व्याख्या (हिन्दी) सॉर्ट-मर्ज जॉइन: (1) जॉइन एट्रिब्यूट पर आर और एस को सॉर्ट करें (ओ(एन लॉग एन + एम लॉग एम))। (2) मर्ज: दोनों क्रमबद्ध संबंधों को एक साथ मिलान करने वाली जॉइन कुंजी (ओ (एन + एम)) को रैखिक रूप से स्कैन करें। कुल: ओ(एन लॉग एन + एम लॉग एम)। सबसे कुशल: जब इनपुट पूर्व-सॉर्ट किए जाते हैं (क्लस्टर इंडेक्स), जब जॉइन प्राथमिक कुंजी पर होता है, या जब परिणाम बड़ा होता है (हैश जॉइन मेमोरी प्रेशर)।
1604
EN + हिं Medium
GB What is the difference between a hash join and a merge join in terms of memory requirements?
IN मेमोरी आवश्यकताओं के संदर्भ में हैश जॉइन और मर्ज जॉइन के बीच क्या अंतर है?
A
Merge join requires more memory than hash join मर्ज जॉइन के लिए हैश जॉइन की तुलना में अधिक मेमोरी की आवश्यकता होती है
B
They have identical memory requirements उनकी स्मृति आवश्यकताएँ समान हैं
C
Neither join algorithm uses memory कोई भी जॉइन एल्गोरिदम मेमोरी का उपयोग नहीं करता है
D
Hash join requires memory to store the entire smaller relation (build side) in a hash table - memory sensitive; merge join requires memory only for sort buffers - can spill to disk more gracefully; but merge join has higher CPU cost from sorting हैश जॉइन के लिए पूरे छोटे रिलेशन (बिल्ड साइड) को हैश टेबल में स्टोर करने के लिए मेमोरी की आवश्यकता होती है - मेमोरी सेंसिटिव; मर्ज जॉइन के लिए केवल सॉर्ट बफ़र्स के लिए मेमोरी की आवश्यकता होती है - डिस्क पर अधिक सुंदर ढंग से फैल सकता है; लेकिन मर्ज जॉइन में सॉर्टिंग से सीपीयू लागत अधिक होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hash join: requires entire smaller table in memory (build phase). If it does not fit: grace hash join (partitioned to disk, more I/O). Memory sensitive. Merge join: requires sort buffers (can be small); external merge sort handles data larger than memory gracefully. Trade-off: hash join is faster when memory available; merge join more memory-resilient.
व्याख्या (हिन्दी) हैश जॉइन: मेमोरी में संपूर्ण छोटी तालिका की आवश्यकता होती है (बिल्ड चरण)। यदि यह फिट नहीं होता है: ग्रेस हैश जॉइन (डिस्क में विभाजित, अधिक I/O)। स्मृति संवेदनशील. मर्ज जॉइन: सॉर्ट बफ़र्स की आवश्यकता है (छोटा हो सकता है); बाहरी मर्ज सॉर्ट मेमोरी से बड़े डेटा को शानदार ढंग से संभालता है। ट्रेड-ऑफ़: मेमोरी उपलब्ध होने पर हैश जॉइन तेज़ होता है; मर्ज जॉइन अधिक मेमोरी-लचीला है।
1605
EN + हिं Medium
GB What is the fanout problem in join optimization and how does it affect result set cardinality?
IN जॉइन ऑप्टिमाइज़ेशन में फैनआउट समस्या क्या है और यह परिणाम सेट कार्डिनैलिटी को कैसे प्रभावित करती है?
A
A performance issue when joining more than 10 tables 10 से अधिक तालिकाओं को जोड़ने पर एक प्रदर्शन समस्या
B
Too many tables in a single join एक ही जुड़ाव में बहुत सारी तालिकाएँ
C
A problem where join results have too few rows एक समस्या जहां जुड़ने के परिणामों में बहुत कम पंक्तियाँ हैं
D
When joining tables with M:N or 1:N relationships the result set can be much larger than the input tables due to row multiplication - e.g. joining Customers (1000 rows) to Orders (10000 rows) on 1:N relationship produces 10000 result rows not 1000 M:N या 1:N संबंधों के साथ तालिकाओं को जोड़ते समय पंक्ति गुणन के कारण परिणाम सेट इनपुट तालिकाओं से बहुत बड़ा हो सकता है - उदाहरण के लिए 1:N संबंध पर ग्राहकों (1000 पंक्तियों) को ऑर्डर (10000 पंक्तियों) से जोड़ने पर 1000 नहीं बल्कि 10000 परिणाम पंक्तियाँ उत्पन्न होती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Fanout: each customer row fans out to multiple order rows in a 1:N join. For M:N joins (via junction table): even more fanout. This is why COUNT(*) after a join often returns more rows than expected. Solutions: GROUP BY to aggregate, DISTINCT to deduplicate, or restructure the query to avoid unnecessary fanout.
व्याख्या (हिन्दी) फ़ैनआउट: प्रत्येक ग्राहक पंक्ति 1:एन जॉइन में एकाधिक ऑर्डर पंक्तियों को फ़ैन करती है। एम:एन जॉइन के लिए (जंक्शन टेबल के माध्यम से): और भी अधिक फैनआउट। यही कारण है कि जुड़ने के बाद COUNT(*) अक्सर अपेक्षा से अधिक पंक्तियाँ लौटाता है। समाधान: एकत्रित करने के लिए ग्रुप BY, डुप्लिकेट हटाने के लिए DISTINCT, या अनावश्यक फैनआउट से बचने के लिए क्वेरी का पुनर्गठन करें।
1591–1605 of 2982