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
1606
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.
व्याख्या (हिन्दी) भौतिकीकरण: पहले अस्थायी तालिका में दृश्य परिणाम की गणना करें, फिर उसका उपयोग करें। अच्छा है जब क्वेरी में दृश्य का कई बार उपयोग किया जाता है। क्वेरी संशोधन: दृश्य संदर्भ को उसकी परिभाषा से बदलें, एकल एकीकृत क्वेरी के रूप में अनुकूलित करें। एकल-उपयोग के लिए अच्छा है, ऑप्टिमाइज़र को दृश्य+क्वेरी को एक साथ अनुकूलित करने की अनुमति देता है।
1607
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 सूची में कोई उपश्रेणी नहीं, कोई व्युत्पन्न कॉलम (गणना की गई अभिव्यक्तियाँ) नहीं, डिफ़ॉल्ट के बिना सभी शून्य कॉलम शामिल नहीं होने चाहिए। उल्लंघन दृश्य को केवल पढ़ने योग्य बना देते हैं।
1608
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.
व्याख्या (हिन्दी) ट्रिगर के बजाय: जब उपयोगकर्ता किसी जटिल दृश्य (ज्वाइन, एग्रीगेट, आदि) में सम्मिलित करता है, तो ट्रिगर अवरुद्ध ऑपरेशन के बजाय सक्रिय हो जाता है। ट्रिगर बॉडी में उचित अंतर्निहित आधार तालिकाओं को सम्मिलित/अद्यतन/हटाने के लिए कस्टम तर्क शामिल हैं। किसी भी दृश्य को प्रभावी ढंग से अद्यतन करने योग्य बनाता है।
1609
EN + हिं Medium
GB What is the difference between a simple view and a complex view in terms of DML support?
IN डीएमएल समर्थन के संदर्भ में सरल दृश्य और जटिल दृश्य के बीच क्या अंतर है?
A
Simple views are slower; complex views are faster साधारण दृश्य धीमे होते हैं; जटिल दृश्य तेज़ होते हैं
B
Simple views are stored; complex views are virtual सरल दृश्य संग्रहीत हैं; जटिल दृश्य आभासी हैं
C
Complex views have WITH CHECK OPTION; simple views do not जटिल दृश्यों में चेक विकल्प के साथ है; साधारण दृश्य नहीं होते
D
Simple view (single table no aggregates no DISTINCT): typically supports DML (INSERT/UPDATE/DELETE) through the view. Complex view (multiple tables aggregates GROUP BY DISTINCT UNION): generally NOT directly updatable since the DBMS cannot unambiguously translate DML to base tables सरल दृश्य (एकल तालिका, कोई समुच्चय नहीं, कोई DISTINCT नहीं): आम तौर पर दृश्य के माध्यम से डीएमएल (INSERT/UPDATE/DELETE) का समर्थन करता है। जटिल दृश्य (मल्टीपल टेबल्स ग्रुप बाय डिस्टिंक्ट यूनियन): आम तौर पर सीधे अपडेट करने योग्य नहीं है क्योंकि डीबीएमएस स्पष्ट रूप से डीएमएल को बेस टेबल में अनुवाद नहीं कर सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Simple updatable view: single table, no DISTINCT/GROUP BY/aggregates. UPDATE through view maps directly to base table. Complex view: JOIN of two tables - INSERT through view is ambiguous (which table gets the data?). Aggregate view: UPDATE is meaningless (which base rows to change?). These require INSTEAD OF triggers.
व्याख्या (हिन्दी) सरल अद्यतन करने योग्य दृश्य: एकल तालिका, कोई अलग/समूह BY/समुच्चय नहीं। दृश्य मानचित्रों के माध्यम से सीधे आधार तालिका में अद्यतन करें। जटिल दृश्य: दो तालिकाओं का जुड़ाव - दृश्य के माध्यम से सम्मिलित करना अस्पष्ट है (कौन सी तालिका डेटा प्राप्त करती है?)। समग्र दृश्य: अद्यतन अर्थहीन है (कौन सी आधार पंक्तियाँ बदलनी हैं?)। इन्हें ट्रिगर्स के बजाय आवश्यकता होती है।
1610
EN + हिं Medium
GB What is view staleness in the context of materialized views and how is it managed?
IN भौतिक विचारों के संदर्भ में दृश्य बासीपन क्या है और इसे कैसे प्रबंधित किया जाता है?
A
Views becoming inaccessible due to permission changes अनुमति परिवर्तन के कारण दृश्य अप्राप्य हो रहे हैं
B
The state where a materialized view no longer reflects the current state of its base tables due to subsequent changes; managed by: immediate refresh (on commit) deferred refresh (on demand/scheduled) or fast/incremental refresh (log-based only propagate changes) वह स्थिति जहां एक भौतिक दृश्य बाद के परिवर्तनों के कारण अपनी आधार तालिकाओं की वर्तमान स्थिति को प्रतिबिंबित नहीं करता है; द्वारा प्रबंधित: तत्काल ताज़ा (प्रतिबद्धता पर) विलंबित ताज़ा (मांग/अनुसूचित पर) या तेज़/वृद्धिशील ताज़ा (लॉग-आधारित केवल प्रचारित परिवर्तन)
C
Views becoming outdated in terms of SQL syntax SQL सिंटैक्स के संदर्भ में दृश्य पुराने होते जा रहे हैं
D
Views that reference dropped tables देखें कि संदर्भ तालिकाएँ गिरा दी गईं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Materialized view refresh strategies: COMPLETE: recompute entire result (slow for large views, always current). FAST/INCREMENTAL: use materialized view logs to apply only changes since last refresh (much faster, requires MV logs). ON COMMIT: refresh after each transaction (expensive). ON DEMAND/SCHEDULED: refresh periodically (may serve stale data).
व्याख्या (हिन्दी) भौतिक दृश्य ताज़ा रणनीतियाँ: पूर्ण: संपूर्ण परिणाम की पुनः गणना करें (बड़े दृश्यों के लिए धीमी, हमेशा चालू)। तेज़/वृद्धिशील: अंतिम रीफ्रेश के बाद से केवल परिवर्तन लागू करने के लिए भौतिकीकृत दृश्य लॉग का उपयोग करें (बहुत तेज़, एमवी लॉग की आवश्यकता है)। प्रतिबद्धता पर: प्रत्येक लेनदेन (महंगा) के बाद ताज़ा करें। मांग पर/अनुसूचित: समय-समय पर ताज़ा करें (पुराना डेटा पेश कर सकता है)।
1611
EN + हिं Easy
GB What is the view cascade problem in schema management?
IN स्कीमा प्रबंधन में व्यू कैस्केड समस्या क्या है?
A
Too many views causing performance issues बहुत अधिक दृश्य प्रदर्शन समस्याओं का कारण बन रहे हैं
B
When modifying or dropping a base table affects (invalidates or drops) all views and views-on-views that depend on it - requiring careful dependency tracking and potentially cascading updates to multiple view definitions जब आधार तालिका को संशोधित या हटाया जाता है, तो उस पर निर्भर सभी दृश्य और दृश्य-पर-दृश्य प्रभावित होते हैं (अमान्य हो जाते हैं या हट जाते हैं) - इसके लिए सावधानीपूर्वक निर्भरता ट्रैकिंग और एकाधिक दृश्य परिभाषाओं के लिए संभावित रूप से कैस्केडिंग अपडेट की आवश्यकता होती है।
C
Views creating recursive loops पुनरावर्ती लूप बनाने वाले दृश्य
D
Too many nested views causing stack overflow बहुत सारे नेस्टेड दृश्य स्टैक ओवरफ़्लो का कारण बन रहे हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View cascade: if table T has 10 views, and each view has 3 views-on-views, dropping T affects 40+ objects. Dependency graph must be maintained (system catalog). DROP TABLE t RESTRICT prevents dropping if views exist. DROP TABLE t CASCADE drops table AND all dependent views. Schema change impact analysis is critical.
व्याख्या (हिन्दी) दृश्य कैस्केड: यदि तालिका T में 10 दृश्य हैं, और प्रत्येक दृश्य में 3 दृश्य-पर-दृश्य हैं, तो T छोड़ने से 40+ ऑब्जेक्ट प्रभावित होते हैं। निर्भरता ग्राफ़ बनाए रखा जाना चाहिए (सिस्टम कैटलॉग)। यदि दृश्य मौजूद हैं तो ड्रॉप टेबल टी रिस्ट्रिक्ट ड्रॉपिंग को रोकता है। ड्रॉप टेबल टी कैस्केड ड्रॉप टेबल और सभी आश्रित दृश्य। स्कीमा परिवर्तन प्रभाव विश्लेषण महत्वपूर्ण है।
1612
EN + हिं Medium
GB How does a database ensure security using views?
IN डेटाबेस दृश्यों का उपयोग करके सुरक्षा कैसे सुनिश्चित करता है?
A
Views encrypt data automatically एन्क्रिप्टेड डेटा को स्वचालित रूप से देखता है
B
Views authenticate users automatically दृश्य स्वचालित रूप से उपयोगकर्ताओं को प्रमाणित करते हैं
C
Views apply row-level encryption दृश्य पंक्ति-स्तरीय एन्क्रिप्शन लागू करते हैं
D
Views restrict what data a user can see/modify: create view restricted_emp AS SELECT name dept FROM employee WHERE dept=accounting; grant SELECT on restricted_emp to accounting_user. User cannot access salary other departments or the base table directly - view provides a security perimeter दृश्य प्रतिबंधित करते हैं कि उपयोगकर्ता किस डेटा को देख/संशोधित कर सकता है: दृश्य प्रतिबंधित_एएमपी बनाएं, कर्मचारी से विभाग का नाम चुनें, जहां विभाग = लेखांकन; अकाउंटिंग_यूजर को प्रतिबंधित_ईएमपी पर चयन प्रदान करें। उपयोगकर्ता वेतन अन्य विभागों या आधार तालिका तक सीधे नहीं पहुंच सकता - दृश्य एक सुरक्षा परिधि प्रदान करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View-based security: (1) Create view exposing only permitted rows/columns. (2) GRANT permissions only on the view, REVOKE from base table. (3) Users can only query through the view filter. This provides: column-level security (hide sensitive columns), row-level security (filter by user/dept), and abstraction of base table structure.
व्याख्या (हिन्दी) दृश्य-आधारित सुरक्षा: (1) केवल अनुमत पंक्तियों/स्तंभों को उजागर करते हुए दृश्य बनाएं। (2) केवल दृश्य पर अनुमति दें, आधार तालिका से रद्द करें। (3) उपयोगकर्ता केवल व्यू फ़िल्टर के माध्यम से क्वेरी कर सकते हैं। यह प्रदान करता है: कॉलम-स्तरीय सुरक्षा (संवेदनशील कॉलम छिपाएँ), पंक्ति-स्तरीय सुरक्षा (उपयोगकर्ता/विभाग द्वारा फ़िल्टर), और आधार तालिका संरचना का अमूर्तन।
1613
EN + हिं Easy
GB What is query rewriting through views in materialized view-based optimization?
IN भौतिक दृश्य-आधारित अनुकूलन में दृश्यों के माध्यम से क्वेरी पुनर्लेखन क्या है?
A
The query optimizer automatically recognizes when a user query can be answered using a pre-computed materialized view (even if the query does not reference the view directly) and rewrites the query to use the materialized view for improved performance क्वेरी ऑप्टिमाइज़र स्वचालित रूप से पहचानता है कि उपयोगकर्ता क्वेरी का उत्तर पूर्व-गणना किए गए भौतिक दृश्य का उपयोग करके दिया जा सकता है (भले ही क्वेरी सीधे दृश्य को संदर्भित न करे) और बेहतर प्रदर्शन के लिए भौतिक दृश्य का उपयोग करने के लिए क्वेरी को फिर से लिखता है
B
Manually rewriting queries to avoid using views दृश्यों के उपयोग से बचने के लिए प्रश्नों को मैन्युअल रूप से दोबारा लिखना
C
Rewriting view definitions to improve their performance उनके प्रदर्शन को बेहतर बनाने के लिए दृश्य परिभाषाओं को फिर से लिखना
D
Converting views into stored procedures दृश्यों को संग्रहित प्रक्रियाओं में परिवर्तित करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View-based query rewriting: user queries SELECT dept, SUM(sales) FROM orders GROUP BY dept. Optimizer detects that a materialized view mv_dept_sales already stores this result. Optimizer rewrites the query to SELECT * FROM mv_dept_sales - avoiding the expensive aggregation on large orders table.
व्याख्या (हिन्दी) दृश्य-आधारित क्वेरी पुनर्लेखन: उपयोगकर्ता क्वेरी विभाग द्वारा समूह, ऑर्डर से विभाग, एसयूएम (बिक्री) का चयन करें। ऑप्टिमाइज़र पता लगाता है कि एक भौतिक दृश्य mv_dept_sales पहले से ही इस परिणाम को संग्रहीत करता है। ऑप्टिमाइज़र SELECT * FROM mv_dept_sales के लिए क्वेरी को फिर से लिखता है - बड़े ऑर्डर टेबल पर महंगे एकत्रीकरण से बचता है।
1614
EN + हिं Easy
GB What are indexed views (SQL Server) or materialized views with indexes and what advantage do they provide?
IN अनुक्रमित दृश्य (एसक्यूएल सर्वर) या अनुक्रमित के साथ भौतिक दृश्य क्या हैं और वे क्या लाभ प्रदान करते हैं?
A
Indexed views have a unique clustered index built on top of the stored result allowing the optimizer to use the view like a regular indexed table for lookups range scans and sort operations - not just aggregations अनुक्रमित दृश्यों में संग्रहीत परिणाम के शीर्ष पर निर्मित एक अद्वितीय क्लस्टर इंडेक्स होता है जो ऑप्टिमाइज़र को लुकअप रेंज स्कैन और सॉर्ट ऑपरेशंस के लिए नियमित अनुक्रमित तालिका की तरह दृश्य का उपयोग करने की अनुमति देता है - न कि केवल एकत्रीकरण के लिए
B
They only work with OLAP queries वे केवल OLAP प्रश्नों के साथ काम करते हैं
C
They are faster to create but slower to query वे बनाने में तेज़ हैं लेकिन क्वेरी करने में धीमे हैं
D
They are identical to regular materialized views वे नियमित भौतिक विचारों के समान हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SQL Server indexed view: CREATE VIEW v WITH SCHEMABINDING AS ...; CREATE UNIQUE CLUSTERED INDEX ix_v ON v(key). Now the view is stored like a base table with B-tree indexes. Optimizer can use it for: equality lookups, range scans, merge joins - beyond just covering pre-aggregated data.
व्याख्या (हिन्दी) एसक्यूएल सर्वर अनुक्रमित दृश्य: स्कीमाबाइंडिंग के साथ व्यू वी बनाएं ...; v(कुंजी) पर अद्वितीय क्लस्टर इंडेक्स ix_v बनाएं। अब दृश्य को बी-ट्री इंडेक्स के साथ बेस टेबल की तरह संग्रहीत किया जाता है। ऑप्टिमाइज़र इसका उपयोग इसके लिए कर सकता है: समानता लुकअप, रेंज स्कैन, मर्ज जॉइन - केवल पूर्व-एकत्रित डेटा को कवर करने के अलावा।
1615
EN + हिं Easy
GB What does WITH SCHEMABINDING option on a view definition do in SQL Server?
IN SQL सर्वर में दृश्य परिभाषा पर with SCHEMABINDING विकल्प क्या करता है?
A
It encrypts the view definition यह दृश्य परिभाषा को एन्क्रिप्ट करता है
B
It allows the view to span multiple schemas यह दृश्य को कई स्कीमा को विस्तारित करने की अनुमति देता है
C
It binds the view to the schema of its base tables preventing changes to base tables (DROP column DROP table ALTER type) that would invalidate the view - required for creating indexed views यह दृश्य को उसके आधार तालिकाओं के स्कीमा से बांधता है, जिससे आधार तालिकाओं (DROP कॉलम DROP तालिका ALTER प्रकार) में परिवर्तन को रोका जा सकता है, जो दृश्य को अमान्य कर देगा - अनुक्रमित दृश्य बनाने के लिए आवश्यक है
D
It compresses the view schema यह दृश्य स्कीमा को संपीड़ित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) WITH SCHEMABINDING: the view is bound to its base tables schema. Prevents: DROP COLUMN of a column used in the view, DROP TABLE of a base table, ALTER TABLE changing referenced columns. Required for indexed views in SQL Server. Also prevents accidental breaking schema changes.
व्याख्या (हिन्दी) स्कीमाबाइंडिंग के साथ: दृश्य इसकी बेस टेबल स्कीमा से जुड़ा हुआ है। रोकता है: दृश्य में उपयोग किए गए कॉलम का ड्रॉप कॉलम, बेस टेबल का ड्रॉप टेबल, संदर्भित कॉलम बदलने वाली टेबल बदलें। SQL सर्वर में अनुक्रमित दृश्यों के लिए आवश्यक। स्कीम परिवर्तनों को आकस्मिक रूप से तोड़ने से भी रोकता है।
1616
EN + हिं Easy
GB What is the view freshness trade-off in data warehousing?
IN डेटा वेयरहाउसिंग में व्यू फ्रेशनेस ट्रेड-ऑफ क्या है?
A
Batch views are always more accurate बैच दृश्य हमेशा अधिक सटीक होते हैं
B
They provide identical freshness guarantees वे समान ताजगी की गारंटी प्रदान करते हैं
C
Real-time views: always current but require resources for each base table change (incremental refresh triggers on every write - adds write overhead); Batch/periodic views: may be stale (hours/days old) but no write overhead refreshed efficiently on schedule वास्तविक समय दृश्य: हमेशा चालू लेकिन प्रत्येक आधार तालिका परिवर्तन के लिए संसाधनों की आवश्यकता होती है (प्रत्येक लेखन पर वृद्धिशील ताज़ा ट्रिगर - लेखन ओवरहेड जोड़ता है); बैच/आवधिक दृश्य: बासी हो सकते हैं (घंटे/दिन पुराने) लेकिन शेड्यूल पर कुशलतापूर्वक ताज़ा किया गया कोई लेखन ओवरहेड नहीं
D
Real-time views are always better वास्तविक समय के दृश्य हमेशा बेहतर होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Freshness trade-off: real-time MV refresh adds latency and overhead to every base table write (triggers/log replay). For OLAP workloads where slight staleness is acceptable, batch refresh (nightly rebuild or frequent incremental) is far more efficient. Business requirements determine acceptable lag.
व्याख्या (हिन्दी) ताजगी का व्यापार-बंद: वास्तविक समय एमवी रिफ्रेश प्रत्येक बेस टेबल राइट (ट्रिगर/लॉग रीप्ले) में विलंबता और ओवरहेड जोड़ता है। ओएलएपी वर्कलोड के लिए जहां थोड़ी सी स्थिरता स्वीकार्य है, बैच रिफ्रेश (रात में पुनर्निर्माण या लगातार वृद्धिशील) कहीं अधिक कुशल है। व्यावसायिक आवश्यकताएँ स्वीकार्य अंतराल निर्धारित करती हैं।
1617
EN + हिं Easy
GB Can a view reference another view (view-on-view nesting) and what is the practical implication?
IN क्या एक दृश्य दूसरे दृश्य का संदर्भ दे सकता है (व्यू-ऑन-व्यू नेस्टिंग) और व्यावहारिक निहितार्थ क्या है?
A
Yes views can reference other views creating nested hierarchies; the query processor must resolve all view definitions recursively before execution which can cause: deep dependency chains difficulty debugging and cascading failures if intermediate views change हाँ, दृश्य नेस्टेड पदानुक्रम बनाते हुए अन्य विचारों को संदर्भित कर सकते हैं; क्वेरी प्रोसेसर को निष्पादन से पहले सभी दृश्य परिभाषाओं को पुनरावर्ती रूप से हल करना होगा, जिसके कारण हो सकता है: यदि मध्यवर्ती दृश्य बदलते हैं तो गहरी निर्भरता श्रृंखलाओं में डिबगिंग और कैस्केडिंग विफलताओं में कठिनाई होती है
B
Views cannot reference other views दृश्य अन्य विचारों का संदर्भ नहीं दे सकते
C
Views can only reference base tables दृश्य केवल आधार तालिकाओं का संदर्भ दे सकते हैं
D
Nested views are automatically flattened नेस्टेड दृश्य स्वचालित रूप से समतल हो जाते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View nesting: CREATE VIEW v3 AS SELECT * FROM v2 JOIN ... where v2 references v1 which references base tables. The query processor resolves v3->v2->v1->base tables. Issues: complex dependency trees, difficult debugging, dropping v1 cascades to v2 and v3, deep nesting can confuse the optimizer.
व्याख्या (हिन्दी) नेस्टिंग देखें: चयन के रूप में दृश्य v3 बनाएं * v2 से जुड़ें... जहां v2 संदर्भ v1 है जो आधार तालिकाओं को संदर्भित करता है। क्वेरी प्रोसेसर v3->v2->v1->बेस टेबल का समाधान करता है। मुद्दे: जटिल निर्भरता वृक्ष, कठिन डिबगिंग, v1 कैस्केड को v2 और v3 पर छोड़ना, गहरी नेस्टिंग ऑप्टिमाइज़र को भ्रमित कर सकती है।
1618
EN + हिं Easy
GB What is horizontal vs vertical view partitioning concept in database design using views?
IN दृश्यों का उपयोग करके डेटाबेस डिज़ाइन में क्षैतिज बनाम ऊर्ध्वाधर दृश्य विभाजन अवधारणा क्या है?
A
Horizontal view: restricts ROWS (WHERE clause on base table) exposing a subset of rows to a user group. Vertical view: restricts COLUMNS (SELECT only certain columns) limiting which attributes are visible - both used for security and interface simplification क्षैतिज दृश्य: उपयोगकर्ता समूह में पंक्तियों के सबसेट को उजागर करने वाली पंक्तियों (आधार तालिका पर WHERE खंड) को प्रतिबंधित करता है। लंबवत दृश्य: कॉलम को प्रतिबंधित करता है (केवल कुछ कॉलम चुनें) यह सीमित करता है कि कौन सी विशेषताएँ दिखाई दे रही हैं - दोनों का उपयोग सुरक्षा और इंटरफ़ेस सरलीकरण के लिए किया जाता है
B
Splitting view processing into parallel steps दृश्य प्रसंस्करण को समानांतर चरणों में विभाजित करना
C
Partitioning materialized views across servers सर्वरों में विचारों को भौतिक रूप से विभाजित करना
D
Physical partitioning of view storage दृश्य भंडारण का भौतिक विभाजन
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Horizontal partition view: CREATE VIEW accounting_emp AS SELECT * FROM employee WHERE dept=Accounting (subset of rows). Vertical partition view: CREATE VIEW emp_public AS SELECT id, name, title FROM employee (subset of columns, hides salary, SSN). Combine both for fine-grained access control.
व्याख्या (हिन्दी) क्षैतिज विभाजन दृश्य: चयन के रूप में अकाउंटिंग_एम्प देखें * कर्मचारी से बनाएं जहां विभाग = अकाउंटिंग (पंक्तियों का सबसेट)। लंबवत विभाजन दृश्य: कर्मचारी से चयन आईडी, नाम, शीर्षक के रूप में एम्प_पब्लिक देखें (स्तंभों का सबसेट, वेतन छुपाता है, एसएसएन)। सुक्ष्म अभिगम नियंत्रण के लिए दोनों को मिलाएं।
1619
EN + हिं Medium
GB What is the SQL CREATE OR REPLACE VIEW statement and how does it differ from DROP+CREATE?
IN SQL क्रिएट या रिप्लेस व्यू स्टेटमेंट क्या है और यह DROP+CREATE से कैसे भिन्न है?
A
CREATE OR REPLACE is faster than DROP+CREATE ड्रॉप+क्रिएट की तुलना में क्रिएट या रिप्लेस तेज़ है
B
CREATE OR REPLACE is not standard SQL बनाएं या बदलें मानक SQL नहीं है
C
They are identical operations वे समान परिचालन हैं
D
CREATE OR REPLACE VIEW atomically replaces an existing view definition without dropping it first preserving dependent object permissions and grants (GRANT/REVOKE on the view survive the replace); DROP+CREATE loses all grants requiring them to be re-applied दृश्य बनाएं या बदलें, किसी मौजूदा दृश्य परिभाषा को पहले आश्रित ऑब्जेक्ट अनुमतियों और अनुदानों को संरक्षित किए बिना परमाणु रूप से प्रतिस्थापित करता है (दृश्य पर अनुदान/निरस्तीकरण प्रतिस्थापन से बच जाता है); DROP+CREATE उन सभी अनुदानों को खो देता है जिन्हें दोबारा लागू करने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) CREATE OR REPLACE VIEW: updates view definition in-place. Key benefit: all previously granted permissions on the view are preserved (no need to re-GRANT). DROP VIEW + CREATE VIEW: removes all grants on the view, requiring manual re-granting to all users/roles that had access.
व्याख्या (हिन्दी) दृश्य बनाएं या बदलें: अद्यतन दृश्य परिभाषा को यथास्थान अपडेट करता है। मुख्य लाभ: दृश्य पर पहले दी गई सभी अनुमतियाँ संरक्षित हैं (पुनः प्रदान करने की कोई आवश्यकता नहीं है)। दृश्य ड्रॉप करें + दृश्य बनाएं: दृश्य पर सभी अनुदान हटा देता है, जिसके लिए उन सभी उपयोगकर्ताओं/भूमिकाओं को मैन्युअल रूप से पुनः अनुदान की आवश्यकता होती है जिनके पास पहुंच थी।
1620
EN + हिं Easy
GB In the context of views what is view serializability in data warehouses?
IN विचारों के संदर्भ में डेटा वेयरहाउस में दृश्य क्रमबद्धता क्या है?
A
Ensuring views execute in a serial order यह सुनिश्चित करना कि दृश्य क्रमिक क्रम में निष्पादित हों
B
Preventing concurrent access to view definitions परिभाषाओं को देखने के लिए समवर्ती पहुंच को रोकना
C
Serializing view refresh operations दृश्य ताज़ा संचालन को क्रमबद्ध करना
D
Ensuring that a snapshot of data used to compute a materialized view is consistent (taken at one point in time) so that the view does not contain data from different points in time - achieved through snapshot isolation or table locking during refresh यह सुनिश्चित करना कि भौतिक दृश्य की गणना करने के लिए उपयोग किए गए डेटा का स्नैपशॉट सुसंगत है (एक समय में एक बिंदु पर लिया गया) ताकि दृश्य में समय के विभिन्न बिंदुओं से डेटा शामिल न हो - ताज़ा करने के दौरान स्नैपशॉट अलगाव या टेबल लॉकिंग के माध्यम से प्राप्त किया गया
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View consistency: if a materialized view refresh spans hours and base data changes during refresh, the view may contain data from different points in time (some rows from T1, others from T2). Solution: SNAPSHOT isolation (read consistent snapshot throughout refresh) or lock tables during refresh.
व्याख्या (हिन्दी) स्थिरता देखें: यदि कोई भौतिक दृश्य ताज़ा घंटों तक चलता है और ताज़ा होने के दौरान आधार डेटा बदलता है, तो दृश्य में समय के विभिन्न बिंदुओं से डेटा शामिल हो सकता है (टी 1 से कुछ पंक्तियाँ, टी 2 से अन्य)। समाधान: स्नैपशॉट अलगाव (रीफ्रेश के दौरान लगातार स्नैपशॉट पढ़ें) या रीफ्रेश के दौरान तालिकाओं को लॉक करें।
1606–1620 of 2982