नेस्टेड दृश्य एक अच्छा डेटाबेस डिजाइन है?

Question

मैंने बहुत समय पहले कहीं पढ़ा है। पुस्तक में कहा गया है कि हमें SQL सर्वर में नेस्टेड दृश्य रखने की अनुमति नहीं देनी चाहिए। मुझे इस बात पर यकीन नहीं है कि हम ऐसा क्यों नहीं कर सकते हैं या मुझे गलत बयान याद हो सकते हैं।

छात्र

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

शिक्षकों की

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

स्कूलों

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
     vw_eligible_student s 
     ON s.SchoolID = sh.SchoolID
JOIN 
     vw_eligible_teacher t
     ON s.SchoolID = t.SchoolID

अपने कार्यस्थल पर, मैंने हमारे इन-हाउस डेटाबेस एप्लिकेशन में से एक की जांच की है। मैंने पाया वस्तुओं के माध्यम से जाँच की कि दृश्य की दो या तीन परतें हैं जो एक दूसरे को ढेर करती हैं। इसलिए यह मुझे याद दिला रहा था कि मैंने अतीत में क्या पढ़ा था। क्या कोई इसे समझाने में मदद कर सकता है?

यदि ऐसा करना ठीक नहीं है, तो मैं जानना चाहता हूं कि यह सिर्फ SQL सर्वर तक सीमित है या यह सामान्य रूप से डेटाबेस डिजाइन के लिए है।

अतिरिक्त जानकारी: मैंने अपनी कंपनी से एक उदाहरण अपडेट किया। मैं बहुत अधिक तकनीकी (इस उदाहरण में बहुत सारे कॉलम) के बिना सामान्य होने के लिए थोड़ा बदल देता हूं। अधिकतर नेस्टेड दृश्य जो हमने उपयोग किया है, वह सार या एकत्रित दृश्य पर आधारित है। उदाहरण के लिए, हमारे पास सौ स्तंभों वाली एक बड़ी छात्र तालिका है। कहते हैं, Eligible Student Viewइस वर्ष नामांकन करने वाले छात्रों पर आधारित है। और छात्र पात्र दृश्य अन्य स्थानों जैसे कि संग्रहित-प्रक्रिया में उपयोग कर सकते हैं।

Comments

मैं प्रस्तुत करूंगा कि विशिष्ट प्लेटफॉर्म की परवाह किए बिना समान पेशेवरों और विपक्षों में समान रूप से समानता होगी।

— हारून बर्ट्रेंड

संबंधित StackOverflow पोस्ट ।

— निक चामास

Answer 1

प्लेटफॉर्म के बावजूद, निम्नलिखित टिप्पणी लागू होती है।

(-) नेस्टेड विचार:

• समझना और डीबग करना कठिन है

  उदाहरण के लिए यह कॉलम किस टेबल कॉलम को दर्शाता है? Lemme दृश्य परिभाषाओं के 4 स्तरों के माध्यम से खुदाई ...

• क्वेरी ऑप्टिमाइज़र को सबसे कुशल क्वेरी प्लान के साथ आने के लिए कठिन बनाएं

  देखें इस , यह , यह , और यह वास्तविक सबूत के लिए। इसकी तुलना करें , जो दर्शाता है कि ऑप्टिमाइज़र अक्सर नेस्टेड विचारों को सही ढंग से अनपैक करने और एक इष्टतम योजना का चयन करने के लिए पर्याप्त स्मार्ट है, लेकिन संकलन लागत के बिना नहीं।

  आप आधार तालिका के विरुद्ध लिखे गए दृश्य समकक्ष की तुलना करके प्रदर्शन लागत को माप सकते हैं।

(+) दूसरी ओर, नेस्टेड विचार आपको देते हैं:

• एकत्रीकरण या व्यावसायिक नियमों का केंद्रीयकरण और पुन: उपयोग
• अपनी अंतर्निहित संरचना को अलग करें (अन्य डेटाबेस डेवलपर्स से कहते हैं)

मैंने पाया है कि वे शायद ही कभी आवश्यक हैं।

---

आपके उदाहरण में आप कुछ व्यापारिक परिभाषाओं को केंद्रीकृत और पुन: उपयोग करने के लिए नेस्टेड विचारों का उपयोग कर रहे हैं (जैसे "एक पात्र क्या है?")। यह नेस्टेड विचारों के लिए एक वैध उपयोग है। यदि आप इस डेटाबेस को बनाए रखते हैं या ट्यूनिंग करते हैं, तो उन्हें हटाने के खिलाफ रखने की लागत का वजन करें।

• रखें: नेस्टेड विचारों को रखकर आप ऊपर बताए गए फायदे और नुकसान उठाते हैं।

• निकालें: नेस्टेड विचारों को दूर करने के लिए:

  1. आपको उनके आधार प्रश्नों के साथ विचारों की सभी घटनाओं को प्रतिस्थापित करने की आवश्यकता है।

  2. यदि योग्य छात्र / शिक्षक / विद्यालय की परिभाषा बदल जाती है, तो आपको सभी प्रासंगिक प्रश्नों को अपडेट करना याद रखना चाहिए, जैसा कि प्रासंगिक दृश्य परिभाषा को अपडेट करने के विपरीत है।

Comments

+1 को छोड़कर, मैं क्वेरी ऑप्टिमाइज़र के लिए "कठिन" को "लगभग असंभव" के साथ बदल दूंगा। :)

— जेसन

@ जेसन - मैं सहमत हूं, और मेरी इच्छा है कि मैं कुछ ठोस उदाहरणों से जुड़ सकूं। क्या आप किसी ऐसे संदर्भ के बारे में जानते हैं जो यह समझाता या प्रदर्शित करता है कि ऐसा क्यों है?

— निक चामास

सभी मुझे मिल सकते हैं एक वास्तविक सबूत है कि जब नेस्टेड विचारों का उपयोग किया जाता है, तो वे "चपटा" एसक्यूएल की तुलना में प्रदर्शन की समस्याओं का सामना करते हैं। sqlservercentral.com/blogs/2cents/archive/2010/04/05/… समस्या इस तथ्य से कम होती दिखाई देती है कि डीबी (SQL सर्वर इस मामले में) टेबल में शामिल होने से पहले कुछ फिल्टर लागू नहीं करेगा, और इसलिए क्वेरी को जितना चाहिए उससे अधिक समय लेना चाहिए।

— जेसन

मैं क्वेरी ऑप्टिमाइज़र के मुद्दे पर असहमत हूं, क्योंकि सभी दृश्यों को हल करने के बाद परिणामी क्वेरी समान होगी, चाहे वह कितने भी व्यू ट्रांसफ़ॉर्मेशन से गुज़री हो (इंटरमीडिएट रिजल्ट सेट में कुछ अतिरिक्त कॉलम को छोड़कर, जो ऑप्टिमाइज़र बस ठीक खत्म कर सकता है)। यह डिबगिंग छोड़ देता है; IMO से डीबग करना आसान हो जाता है, क्योंकि इसमें गलत परिणाम देखने के लिए मैं इंटरेस्टेड परिणाम देख सकता हूं।

— साइमन रिक्टर

मैंने एक एम्बेडेड डेटाबेस सर्वर लिखा है, और मेरे लिए, पहले विचारों को हल करना और फिर परिणामी क्वेरी का अनुकूलन स्पष्ट मार्ग था, क्योंकि यह वास्तव में काफी संभावना नहीं है कि विचारों पर सभी प्रश्न सभी कॉलम वापस कर देंगे। मैं एक कारण के बारे में भी नहीं सोच सकता कि क्यों क्वेरी के बीच में दृश्य डेटा को प्राप्त करने से कुछ हासिल होगा, इसलिए यह मेरे लिए एक नो-ब्रेनर था।

— साइमन रिक्टर

Answer 2

कभी-कभी नेस्टेड दृश्यों को दोहराने के लिए समुच्चय का उपयोग किया जाता है। मान लीजिए कि आपके पास एक ऐसा दृश्य है जो संदेशों को गिनता है और उपयोगकर्ता द्वारा उन्हें समूहित करता है, तो आपके पास इस पर एक दृष्टिकोण हो सकता है कि उन उपयोगकर्ताओं की संख्या गिना जाए जिनके पास> 100 संदेश, उस तरह की चीज़ है। यह सबसे प्रभावी है जब आधार दृश्य एक अनुक्रमित दृश्य होता है - आप डेटा को थोड़ा अलग समूहीकरण के साथ प्रतिनिधित्व करने के लिए अभी तक एक और अनुक्रमित दृश्य बनाना नहीं चाहते हैं, क्योंकि अब आप दो बार सूचकांक रखरखाव के लिए भुगतान कर रहे हैं जहां प्रदर्शन संभवतः है मूल दृश्य के खिलाफ पर्याप्त है।

यदि ये सभी नेस्टेड दृश्य हैं, जहाँ आप चयन कर रहे हैं * लेकिन ऑर्डर या शीर्ष को बदलते हुए, ऐसा लगता है कि यह नेस्टेड व्यूज़ के एक समूह की तुलना में पैरामीटर (या इनलाइन टेबल-वैल्यूड फ़ंक्शंस) के साथ संग्रहीत प्रक्रिया के रूप में बेहतर होगा। IMHO।

Comments

"यह सबसे प्रभावी है जब आधार दृश्य एक अनुक्रमित दृश्य है।" महत्वपूर्ण बिंदु।

— निक चामास

Answer 3

एसक्यूएल के बाद के संस्करण (2005+) विचारों के उपयोग को अनुकूलित करने में बेहतर लगते हैं। व्यावसायिक नियमों को समेकित करने के लिए दृश्य सर्वोत्तम हैं। ईजी: जहां मैं काम करता हूं हमारे पास एक टेलीकॉम उत्पाद डेटाबेस है। प्रत्येक उत्पाद एक रेटप्लान को सौंपा गया है, और उस दर को बाहर निकाला जा सकता है, और रेटप्लान पर दरों को बढ़ाया / संशोधित या सक्रिय किया जा सकता है।

इसे आसान बनाने के लिए, हम नेस्टेड विचार कर सकते हैं। 1 दृश्य, जो भी टेबल की जरूरत है, और किसी भी आवश्यक डेटा को वापस करने के लिए अगले स्तर के दृश्यों का उपयोग करने की आवश्यकता होती है, का उपयोग कर दर को उनके दरों में जोड़ता है। 2 दृश्य (ओं) केवल सक्रिय दर और उनकी सक्रिय दरों को अलग कर सकते हैं। या, सिर्फ ग्राहक दर। या कर्मचारी दरों (कर्मचारी छूट के लिए)। या व्यवसाय बनाम आवासीय ग्राहक दरें। (रेटप्लान्स जटिल हो सकते हैं)। मुद्दा यह है कि, फाउंडेशन व्यू रेटप्लांस के लिए हमारे समग्र व्यापार तर्क को सुनिश्चित करता है और दरें एक स्थान पर एक साथ ठीक से जुड़ जाती हैं। विचारों की अगली परत हमें विशिष्ट दर (प्रकार, सक्रिय / निष्क्रिय, आदि) पर अधिक ध्यान देती है।

मैं मानता हूं कि यदि आप एक ही समय में प्रश्नों और विचारों का निर्माण कर रहे हैं, तो दृश्य डिबगिंग को गन्दा बना सकते हैं। लेकिन, यदि आप आजमाए हुए दृष्टिकोण का उपयोग कर रहे हैं, तो यह डीबग करना आसान बना देता है। आप जानते हैं कि दृश्य पहले से ही रिंगर के माध्यम से है, इसलिए आप जानते हैं कि यह समस्या का कारण नहीं है।

मुद्दे आपके विचारों के साथ आ सकते हैं, हालाँकि। "क्या होगा यदि एक उत्पाद केवल एक निष्क्रिय दर से जुड़ा हो?" या "क्या होगा अगर एक दर केवल उस पर निष्क्रिय दर है?" ठीक है, कि उपयोगकर्ता त्रुटियों को पकड़ने वाले तर्क के साथ फ्रंट-एंड स्तर पर पकड़ा जा सकता है। "त्रुटि, उत्पाद निष्क्रिय दर पर है ... कृपया सही करें"। हम बिलिंग ऑडिट से पहले इसे दोबारा जांचने के लिए क्वेरी ऑडिट भी चला सकते हैं। (सभी योजनाओं का चयन करें और बाईं ओर सक्रिय रेटप्लान दृश्य में शामिल हों, केवल उन योजनाओं को लौटाएं जिन्हें एक सक्रिय दर नहीं मिलता है क्योंकि समस्याओं को संबोधित करने की आवश्यकता है)।

इसके बारे में अच्छी बात यह है कि आप रिपोर्टिंग, बिलिंग, आदि के लिए प्रश्नों को बहुत कम कर सकते हैं। आपके पास एक ग्राहक खाता दृश्य हो सकता है, फिर सिर्फ सक्रिय ग्राहकों का 2-स्तरीय दृश्य। ग्राहक पते के दृश्य के साथ टीम। उत्पाद की दृष्टि से वह टीम (जो ग्राहक के पास है) टीम है कि उत्पाद (ओं) दर देखने के लिए। उत्पाद सुविधाओं को देखते हुए टीम। अखंडता सुनिश्चित करने के लिए प्रत्येक परीक्षण-एन-त्रुटी को देखें, देखें, देखें। विचारों का उपयोग करते हुए आपकी अंतिम क्वेरी बहुत कॉम्पैक्ट है।

संपादित करें:

उदाहरण के तौर पर कि किस तरह से तालिकाओं की एक सपाट क्वेरी की तुलना में दृश्य बेहतर होगा ... हमारे पास कुछ बदलाव करने के लिए एक अस्थायी ठेकेदार था। उन्होंने उसे बताया कि चीजों के लिए विचार हैं, लेकिन उसने अपने सभी प्रश्नों को समतल करने का फैसला किया। बिलिंग उनके कुछ प्रश्नों से दूर चल रही थी। वे चीजों पर कई दर और दर प्राप्त करते रहे। यह पता चलता है कि उनके प्रश्नों के मानदंड गायब थे, केवल दरों को बिल की अनुमति देने के लिए यदि वे प्रारंभ और समाप्ति की तारीखों के बीच थे, तो उस दर / दर का उपयोग करने वाले थे उफ़। यदि वह दृश्य का उपयोग करता, तो यह पहले से ही उस तर्क को ध्यान में रखता।

मूल रूप से, आपको प्रदर्शन बनाम विवेक का वजन करना होगा। हो सकता है कि आप डेटाबेस के प्रदर्शन को बढ़ाने के लिए सभी प्रकार के फैंसी सामान कर सकते हैं। लेकिन, अगर इसका मतलब यह है कि किसी नए व्यक्ति को लेने-देने / बनाए रखने का एक बुरा सपना है, तो क्या यह वास्तव में इसके लायक है? क्या यह वास्तव में नए आदमी को अजीब-ए-मोल खेलने के लायक है, जिसमें सभी प्रश्नों को खोजने की जरूरत है जो उनके तर्क को बदलने की आवश्यकता है (और उन्हें भूल जाने / वसा को छीनने का जोखिम) बी / सी किसी ने निर्णय लिया कि विचार "खराब" हैं। 100 में से कुछ अन्य प्रश्नों में उपयोग किए जा सकने वाले कुछ मुख्य व्यावसायिक तर्क को समेकित नहीं किया? यह वास्तव में आपके व्यवसाय और आपके IT / IS / DB टीम पर निर्भर है। लेकिन, मैं प्रदर्शन पर स्पष्टता और एकल-स्रोत समेकन पसंद करूंगा।

Answer 4

वास्तविक मुद्दा खुद में निहित विचार नहीं है। वास्तविक मुद्दा नेस्टेड विचारों का प्रसार है क्योंकि डेवलपर्स मौजूदा विचारों पर अतिरिक्त ट्विक्स को परत करते हैं। मुझे एक नेस्टेड व्यू 4 लेयर वाले क्वेश्चन मिले हैं जो वास्तव में एक परिभाषा में शामिल हो गए हैं। विश्लेषण करने और समस्या हल करने के बजाय आसान रास्ता निकालने की हमारी प्रवृत्ति समस्या की जड़ है।

Answer 5

मेरे वातावरण में, हम उत्पादन सर्वर से रिपोर्ट सर्वर पर बहुत सारी तालिकाएँ दोहराते हैं। रिपोर्ट सर्वर पर हमारे पास बहुत सारे विचार हैं जो प्रतिरूपित उत्पादन तालिकाओं पर आधारित हैं और निहित हैं। प्रतिकृति शुरू होने से पहले, हमें प्रतिकृति को संभव बनाने के लिए सभी विचारों को दूर करना होगा (हम ड्रॉप का उपयोग करते हैं और बनाते हैं क्योंकि तालिका संरचना अक्सर उत्पादन में बदल जाती है)। प्रतिकृति समाप्त होने के बाद, हमें सभी विचारों का पुनर्निर्माण करना होगा।

अब यहाँ का मज़ेदार हिस्सा है: क्योंकि बहुत से विचार नेस्टेड हैं, हमें उन्हें एक विशिष्ट क्रम में पुनर्निर्माण करना होगा। विचारों की परिभाषा में कोई भी बदलाव करते समय हमें सही पुनर्निर्माण के आदेश को ध्यान में रखना चाहिए। यह कुल गड़बड़ है। यदि आप प्रतिकृति का उपयोग करते हैं या बस अपनी तालिकाओं का उपयोग करते हैं और विचारों के लिए स्रोत हैं, तो मैं नेस्टेड दृश्यों का उपयोग करके दृढ़ता से हतोत्साहित करता हूं।

प्रदर्शन दूसरी बात है। अन्य दृश्यों पर आधारित दृश्य निष्पादित करने के लिए और कुछ नहीं बल्कि कई प्रश्न हैं। बड़ी क्वेरी को एक साथ रखना, एक नौकरी बनाना और उसमें से एक तालिका बनाना आसान है। आसान और प्रदर्शन में सुधार।