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
2146
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 एकत्रीकरण के बिना जुड़ने से बड़े परिणाम सेट उत्पन्न होते हैं।
2147
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 क्वेरीज़ के लिए अत्यधिक कुशल जो एकाधिक आयाम विशेषताओं पर फ़िल्टर करती हैं।
2148
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|) पृष्ठ पढ़ता/लिखता है। मेमोरी से बड़े डेटा को संभालता है।
2149
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) हैश जॉइन स्क्यू: स्थिति=सक्रिय बकेट को अधिकांश पंक्तियाँ मिलती हैं, जिससे मेमोरी ओवरफ्लो हो जाती है। समाधान: बिटमैप इंडेक्स (कम कार्डिनैलिटी ओएलएपी के लिए बढ़िया), स्क्यू हैंडलिंग (हॉट कुंजी मानों के लिए अलग प्रसंस्करण)।
2150
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 क्लॉज को प्राथमिकता दें।
2151
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) की गणना करें, मिलान के लिए हैश तालिका में देखें। बिल्ड साइड के रूप में छोटी टेबल मेमोरी में हैश टेबल को फिट करती है, ग्रेस हैश जॉइन ओवरहेड से बचती है।
2152
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.
व्याख्या (हिन्दी) दाएं जोड़ (ए, बी) = बाएं जोड़ (बी, ए) उलटे तालिका क्रम के साथ। चूंकि लेफ्ट जॉइन अधिक प्राकृतिक है (बाएं से दाएं पढ़ें: मुझे बाईं तालिका की सभी चीजें चाहिए), अधिकांश डेवलपर्स राइट जॉइन से बचते हैं और लेफ्ट जॉइन का उपयोग करने के लिए तालिकाओं को फिर से व्यवस्थित करते हैं। परिणाम समान हैं; यह एक कोड पठनीयता सम्मेलन है।
2153
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 क्लॉज में, तालिकाओं के बीच जुड़ने की स्थिति की पहचान करें। समूह तालिकाएँ जिनमें एक साथ सीधे जुड़ने की स्थितियाँ होती हैं। क्रॉस उत्पाद के माध्यम से जुड़े बिना किसी प्रत्यक्ष जुड़ाव की स्थिति वाली तालिकाएँ - ऑप्टिमाइज़र इसमें तब तक देरी करता है जब तक कि अन्य जुड़ने से पंक्ति की संख्या कम नहीं हो जाती। क्रॉस उत्पाद जल्दी = विनाशकारी प्रदर्शन।
2154
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) से अलग करता है, स्पष्ट इरादा, बाहरी जुड़ाव के लिए आवश्यक है।
2155
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) मर्ज: दोनों क्रमबद्ध संबंधों को एक साथ मिलान करने वाली जॉइन कुंजी (ओ (एन + एम)) को रैखिक रूप से स्कैन करें। कुल: ओ(एन लॉग एन + एम लॉग एम)। सबसे कुशल: जब इनपुट पूर्व-सॉर्ट किए जाते हैं (क्लस्टर इंडेक्स), जब जॉइन प्राथमिक कुंजी पर होता है, या जब परिणाम बड़ा होता है (हैश जॉइन मेमोरी प्रेशर)।
2156
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)। स्मृति संवेदनशील. मर्ज जॉइन: सॉर्ट बफ़र्स की आवश्यकता है (छोटा हो सकता है); बाहरी मर्ज सॉर्ट मेमोरी से बड़े डेटा को शानदार ढंग से संभालता है। ट्रेड-ऑफ़: मेमोरी उपलब्ध होने पर हैश जॉइन तेज़ होता है; मर्ज जॉइन अधिक मेमोरी-लचीला है।
2157
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, या अनावश्यक फैनआउट से बचने के लिए क्वेरी का पुनर्गठन करें।
2158
EN + हिं Medium
GB What is the view materialization strategy in query processing and how does it differ from view substitution?
IN क्वेरी प्रोसेसिंग में व्यू मैटीरियलाइजेशन रणनीति क्या है और यह व्यू प्रतिस्थापन से कैसे भिन्न है?
A
They are identical strategies with different names वे अलग-अलग नामों वाली समान रणनीतियाँ हैं
B
View materialization is always better than query modification क्वेरी संशोधन की तुलना में दृश्य का भौतिकीकरण हमेशा बेहतर होता है
C
View substitution stores results permanently; materialization does not प्रतिस्थापन भंडार परिणाम स्थायी रूप से देखें; भौतिकीकरण नहीं होता है
D
View materialization: physically compute and store the view result before executing the main query; Query modification: substitute the view definition into the query and process as one combined query - materialization is better for reused views modification is simpler for single use भौतिकीकरण देखें: मुख्य क्वेरी निष्पादित करने से पहले दृश्य परिणाम की भौतिक रूप से गणना करें और संग्रहीत करें; क्वेरी संशोधन: दृश्य परिभाषा को क्वेरी में प्रतिस्थापित करें और एक संयुक्त क्वेरी के रूप में प्रक्रिया करें - पुन: उपयोग किए गए दृश्यों के लिए भौतिकीकरण बेहतर है, एकल उपयोग के लिए संशोधन सरल है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Materialization: compute view result into temp table first, then use it. Good when view is used multiple times in query. Query modification: replace view reference with its definition, optimize as single unified query. Good for single-use, allows optimizer to optimize view+query together.
व्याख्या (हिन्दी) भौतिकीकरण: पहले अस्थायी तालिका में दृश्य परिणाम की गणना करें, फिर उसका उपयोग करें। अच्छा है जब क्वेरी में दृश्य का कई बार उपयोग किया जाता है। क्वेरी संशोधन: दृश्य संदर्भ को उसकी परिभाषा से बदलें, एकल एकीकृत क्वेरी के रूप में अनुकूलित करें। एकल-उपयोग के लिए अच्छा है, ऑप्टिमाइज़र को दृश्य+क्वेरी को एक साथ अनुकूलित करने की अनुमति देता है।
2159
EN + हिं Medium
GB Under what conditions can a SQL view be updated (INSERT UPDATE DELETE) in standard SQL?
IN मानक SQL में SQL दृश्य को किन परिस्थितियों में अद्यतन (INSERT UPDATE DELETE) किया जा सकता है?
A
Views can never be updated directly दृश्य कभी भी सीधे अद्यतन नहीं किए जा सकते
B
A view is updatable if: it is based on a single base table (no joins) has no DISTINCT or GROUP BY/HAVING/aggregate functions no subqueries in SELECT list no UNION/INTERSECT/EXCEPT and the WHERE clause allows identification of the base table rows एक दृश्य अद्यतन करने योग्य है यदि: यह एकल आधार तालिका पर आधारित है (कोई जुड़ाव नहीं) इसमें कोई DISTINCT या GROUP BY/HAVING/aggregate फ़ंक्शन नहीं है, SELECT सूची में कोई उपश्रेणी नहीं है, कोई UNION/INTERSECT/EXCEPT नहीं है और WHERE क्लॉज आधार तालिका पंक्तियों की पहचान की अनुमति देता है।
C
All views can always be updated सभी दृश्य हमेशा अद्यतन किए जा सकते हैं
D
Only views with WITH CHECK OPTION can be updated केवल चेक विकल्प वाले दृश्य ही अपडेट किए जा सकते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Standard SQL updatable view conditions: single base table (no joins), no DISTINCT, no set operations, no aggregates or GROUP BY/HAVING, no subqueries in SELECT list, no derived columns (computed expressions), must include all NOT NULL columns without defaults. Violations make the view read-only.
व्याख्या (हिन्दी) मानक SQL अद्यतन करने योग्य दृश्य स्थितियाँ: एकल आधार तालिका (कोई जोड़ नहीं), कोई DISTINCT नहीं, कोई सेट संचालन नहीं, कोई समुच्चय या ग्रुप BY/HAVING नहीं, SELECT सूची में कोई उपश्रेणी नहीं, कोई व्युत्पन्न कॉलम (गणना की गई अभिव्यक्तियाँ) नहीं, डिफ़ॉल्ट के बिना सभी शून्य कॉलम शामिल नहीं होने चाहिए। उल्लंघन दृश्य को केवल पढ़ने योग्य बना देते हैं।
2160
EN + हिं Medium
GB What is the purpose of INSTEAD OF triggers on views and what problem do they solve?
IN विचारों पर INSTEAD OF ट्रिगर्स का उद्देश्य क्या है और वे किस समस्या का समाधान करते हैं?
A
Triggers that prevent all DML on views ट्रिगर जो सभी डीएमएल को दृश्यों पर रोकते हैं
B
Triggers defined on views that fire INSTEAD OF the attempted INSERT/UPDATE/DELETE allowing custom logic to translate the DML operation on the view into appropriate operations on the underlying base tables - enabling updates on otherwise non-updatable views ट्रिगर उन विचारों पर परिभाषित होते हैं जो प्रयास किए गए INSERT/UPDATE/DELETE के बजाय सक्रिय होते हैं, जो कस्टम तर्क को दृश्य पर DML ऑपरेशन को अंतर्निहित आधार तालिकाओं पर उचित संचालन में अनुवाद करने की अनुमति देता है - अन्यथा गैर-अद्यतन योग्य दृश्यों पर अपडेट सक्षम करना
C
Triggers that update views automatically when base tables change ट्रिगर जो बेस टेबल बदलने पर स्वचालित रूप से दृश्य अपडेट करते हैं
D
Triggers that replace view definitions ट्रिगर जो दृश्य परिभाषाओं को प्रतिस्थापित करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) INSTEAD OF triggers: when user INSERTs into a complex view (join, aggregate, etc.), the trigger fires INSTEAD OF the blocked operation. The trigger body contains custom logic to INSERT/UPDATE/DELETE the appropriate underlying base tables. Effectively makes any view updatable.
व्याख्या (हिन्दी) ट्रिगर के बजाय: जब उपयोगकर्ता किसी जटिल दृश्य (ज्वाइन, एग्रीगेट, आदि) में सम्मिलित करता है, तो ट्रिगर अवरुद्ध ऑपरेशन के बजाय सक्रिय हो जाता है। ट्रिगर बॉडी में उचित अंतर्निहित आधार तालिकाओं को सम्मिलित/अद्यतन/हटाने के लिए कस्टम तर्क शामिल हैं। किसी भी दृश्य को प्रभावी ढंग से अद्यतन करने योग्य बनाता है।
2146–2160 of 2982