2008-09-03 13 views
27

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

डेटाबेस में लगभग 600 टेबल थे और अत्यधिक सामान्यीकृत था, इसलिए अधिकांश उपयोगी एसक्यूएल आवश्यक रूप से वर्बोज़ था।

कई सालों बाद मैं प्रतिबंध से कम से कम एक बुरा परिणाम देख सकता हूं - हमारे पास कई सैकड़ों घने, लंबी संग्रहित प्रोसेस हैं जो अनजान हैं।

हिंडसाइट में मैं कहूंगा कि यह एक बुरा निर्णय था, लेकिन एसक्यूएल विचारों के साथ आपके अनुभव क्या हैं? क्या आपने उन्हें प्रदर्शन के लिए बुरा पाया है? जब वे उचित हैं या उचित नहीं हैं तो कोई अन्य विचार? प्रति-और-चिपकाएं

पुन: उपयोग के लिए एक दृश्य बनाने के द्वारा कोड के माध्यम से

वह था उत्साहजनक कोड पुन: उपयोग:

उत्तर

29

विचारों के लिए कुछ बहुत अच्छे उपयोग हैं; मैंने उन्हें ट्यूनिंग के लिए बहुत कुछ उपयोग किया है और सूचना के कम सामान्यीकृत सेट को उजागर करने के लिए, या एक से अधिक परिणाम सेट में कई चयनों से यूनियन-आईएनजी परिणामों के लिए उपयोग किया है।

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

संयोग से, मैं कभी भी आर्किटेक्चरल "नियम" का प्रशंसक नहीं रहा हूं जो डेवलपर्स को खुद को चोट पहुंचाने पर आधारित हैं। इन नियमों में अक्सर अनपेक्षित दुष्प्रभाव होते हैं - आखिरी जगह मैंने काम किया है डेटाबेस में एनयूएलएल का उपयोग करने की अनुमति नहीं है, क्योंकि डेवलपर्स शून्य की जांच करना भूल सकते हैं। इसने हमें "1/1/1900" तिथियों के आसपास काम करने के लिए मजबूर कर दिया और डेटाबेस के खिलाफ बनाए गए सभी सॉफ़्टवेयर में "0" के लिए डिफॉल्ट पूर्णांक, और उन स्थानों के आसपास काम करने वाले देवों के कारण बग की एक लीटनी पेश की जहां न्यूल उचित मूल्य था ।

+7

+1 लेकिन मैं उन परिस्थितियों में आया हूं जहां खराब डिजाइन किए गए विचारों ने भयंकर प्रदर्शन किया है। स्थिति SQL2K थी जिसमें दो विचार थे जो यूनियनों का प्रदर्शन करते थे और फिर तीसरे दृश्य में शामिल होते थे। उस विशिष्ट मामले में प्रदर्शन हिट 1,000 गुना धीमा था। – BlackWasp

+0

इस पर आया था। हम ऐसी कंपनी के लिए परामर्श प्रदान कर रहे हैं जिसमें प्रदर्शन समस्याएं हैं। हम उन्हें अपने मौजूदा सिस्टम के साथ जुड़ने के लिए पीडीए आधारित समाधान भी दे रहे हैं। उनके पास प्रत्येक टेबल के लिए एक दृश्य है। और उनके सिस्टम द्वारा उपयोग की जाने वाली प्रत्येक क्वेरी के लिए उनके पास एक दृश्य है। और वे चाहते हैं कि हम अपने डीडी तक पहुंचने के लिए हमारे पीडीए आधारित सिस्टम द्वारा उपयोग की जाने वाली प्रत्येक क्वेरी के लिए प्रत्येक को एक दृश्य बनाएं। मैंने उन्हें बताया है कि यह एक भयानक विचार है। क्या मुझे चीजों को करने के अपने तरीके से आगे बढ़ना चाहिए? मैं इसे SO पर एक अलग प्रश्न के रूप में पोस्ट कर सकता हूं। –

19

आप अपनी खुद की प्रश्न का उत्तर दिया। यदि दृश्य खराब प्रदर्शन करता है, तो यदि आपके पास कई स्थानों पर एक ही खराब प्रदर्शन कोड है तो ट्रैक करना अधिक आसान होगा।

5

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

1

हम सीएसवी फाइलों में हमारे सभी सरल डेटा निर्यात के लिए विचारों का उपयोग करते हैं। यह एक पैकेज लिखने और पैकेज के भीतर एसक्यूएल को एम्बेड करने की प्रक्रिया को सरल बनाता है जो बोझिल और कठिन हो जाता है।

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

3

विचार विज्ञापन-प्रसार प्रश्नों के लिए अच्छे हैं, जिस तरह से डीबीए दृश्यों के पीछे करता है जब उसे सिस्टम के साथ क्या चल रहा है यह देखने के लिए डेटा तक त्वरित पहुंच की आवश्यकता होती है।

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

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

4

सभी शक्तियों की तरह, विचारों का अपना अंधेरा पक्ष होता है। हालांकि, आप खराब प्रदर्शन कोड लिखने वाले किसी के लिए विचारों को दोष नहीं दे सकते। इसके अलावा विचार कुछ कॉलम के संपर्क को सीमित कर सकते हैं और अतिरिक्त सुरक्षा प्रदान कर सकते हैं।

0

चलो अगर मैं एक लंगड़ा सादृश्य के साथ आ सकते हैं देखते हैं ...

"मैं एक फिलिप्स का शराबी की जरूरत नहीं है। मैं एक फ्लैट सिर और मिक्सी ले!"

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

4

एक बात जिसका अब तक उल्लेख नहीं किया गया है, उपयोगकर्ताओं के विज्ञापन रिपोर्टिंग या इसी तरह के उपयोगकर्ताओं को समाप्त करने के लिए डेटा की तार्किक तस्वीर प्रदान करने के लिए विचारों का उपयोग है।

यह दो गुण है:

  1. एकल "टेबल" करने के लिए उपयोगकर्ता की अनुमति के लिए डेटा बल्कि वे संभावित जटिल मिलती है बाहर काम करने के लिए (क्योंकि डेटाबेस सामान्यीकृत है) अपेक्षाकृत गैर तकनीकी प्रयोक्ताओं की आवश्यकता होती है उम्मीद युक्त
  2. यह अंत उपयोगकर्ताओं को डेटा या संरचना को उजागर किए बिना कुछ हद तक पहुंच प्रदान करने का साधन प्रदान करता है।

गैर-विज्ञापन रिपोर्टिंग के साथ भी कभी-कभी रिपोर्टिंग सिस्टम में एक दृश्य प्रदान करने के लिए यह कभी-कभी आसानी से आसान होता है जिसमें अवशेष डेटा होता है, जो डेटा के उत्पादन को अच्छी तरह से प्रस्तुत करने से अलग करता है।

1

कुछ समय पहले मैं बार देखा गया :)

करने के लिए कोड का इस्तेमाल किया है कि विचारों से बनाया विचारों से बनाया विचारों ... यह एक ** में एक दर्द था बनाए रखने के लिए कोशिश की है, तो मैं मिल गया एक छोटे से एलर्जी मैं आम तौर पर सीधे टेबल के साथ काम करना पसंद करता हूं, खासकर वेब अनुप्रयोगों के लिए जहां गति एक मुख्य चिंता है। टेबल तक पहुंचने पर आपको सर्वश्रेष्ठ प्रदर्शन प्राप्त करने के लिए अपने SQL-Queries को ट्विक करने का मौका मिलता है। "प्रीकंपिल्ड"/कैश किए गए कामकाजी योजनाएं विचारों का एक लाभ हो सकती हैं, लेकिन कई मामलों में सभी दिए गए मानकों के साथ समय-समय पर संकलन और जहां पर विचार किए गए खंडों का परिणाम सभी पर तेजी से प्रसंस्करण होगा।

हालांकि, अगर पर्याप्त रूप से उपयोग किया जाता है, तो यह पूरी तरह से विचारों को रद्द नहीं करता है। उदाहरण के लिए, यदि आपको इसकी आवश्यकता है तो प्रत्येक स्थिति के लिए एक टेक्स्ट स्पष्टीकरण प्राप्त करने के लिए आप "users_status" तालिका से जुड़े "उपयोगकर्ता" तालिका के साथ एक दृश्य का उपयोग कर सकते हैं। हालांकि अगर आपको स्पष्टीकरण की आवश्यकता नहीं है: "उपयोगकर्ता" तालिका का उपयोग करें, न कि दृश्य। हमेशा के रूप में: अपने मस्तिष्क का प्रयोग करें!

16

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

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

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

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

ब्लैम की तरह मैं व्यक्तिगत रूप से संग्रहीत प्रोसेस की तुलना में उन्हें बनाए रखने में आसान नहीं पाया है।

अक्टूबर 2010 में संपादित करने के लिए संपादित किया गया: चूंकि मैंने इसे मूल रूप से लिखा है, इसलिए मुझे उन लोगों द्वारा डिजाइन किए गए कुछ डेटाबेस के साथ काम करने का मौका मिला है, जो विचारों का उपयोग करने के लिए आदी थे। इससे भी बदतर उन्होंने उन विचारों का उपयोग किया जो विचारों को बुलाते थे (उस बिंदु पर जहां अंत में हम टेबल की संख्या की सीमा को हिट करते थे जिन्हें कहा जा सकता है)। यह एक प्रदर्शन दुःस्वप्न था। रिकॉर्ड के एक साधारण गिनती (*) को एक दृश्य में प्राप्त करने में 8 मिनट लग गए और डेटा प्राप्त करने में काफी समय लगा। यदि आप विचारों का उपयोग करते हैं, तो उन विचारों का उपयोग करने से बहुत सावधान रहें जो अन्य विचारों को कॉल करते हैं। आप एक ऐसी प्रणाली का निर्माण करेंगे जो शायद उत्पादन पर सामान्य प्रदर्शन भार के तहत काम नहीं करेगा। SQL सर्वर में आप केवल उन दृश्यों को इंडेक्स कर सकते हैं जो अन्य दृश्यों को कॉल नहीं करते हैं, इसलिए जब आप किसी श्रृंखला में दृश्यों का उपयोग करते हैं तो क्या होता है, यह है कि संपूर्ण रिकॉर्ड सेट प्रत्येक दृश्य के लिए बनाया जाना चाहिए और यह तब तक नहीं है जब तक आप आखिरी एक कि जहां खंड मानदंड लागू होते हैं। आपको तीन देखने के लिए लाखों रिकॉर्ड जेनरेट करने की आवश्यकता हो सकती है। आप एक ही तालिका में 6 बार शामिल हो सकते हैं जब आपको वास्तव में केवल एक बार इसमें शामिल होने की आवश्यकता होती है, तो आप अंतिम परिणाम सेट में आवश्यकतानुसार कई और कॉलम वापस कर सकते हैं।

+1

अच्छा जवाब ब्रूव +1, चर्चा, चीरियोस में कुछ और मजेदार विवरण लाने के लिए धन्यवाद! –

+0

यही वह है जो मैं चाहता था। मैं हर समय विचारों का उपयोग करने के खिलाफ हूँ ... –

0

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

यह सुरक्षा अमूर्त लाभ तब भी लागू होता है जब अंतिम उपयोगकर्ता विज्ञापन-संबंधी प्रश्नों के लिए विचारों का उपयोग किया जाता है; यदि हमारे पास हमारे डेटा का एक उचित, चपटा, डेटा वेयरहाउस प्रतिनिधित्व था, तो इससे कम लाभ होगा।

0

विचार जटिल प्रश्नों के आकार को भी कम कर सकते हैं (उसी तरह संग्रहीत प्रोसेस कर सकते हैं)।

यह बहुत व्यस्त डेटाबेस के लिए नेटवर्क बैंडविड्थ को कम कर सकता है।

0

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

उदाहरण के लिए, यदि आपको किसी तालिका के केवल 5 फ़ील्ड की आवश्यकता है जिसमें कई (30 या 40 कहें) एक ओआरएम ढांचा तालिका का प्रतिनिधित्व करने के लिए एक इकाई बनायेगा।

इसका मतलब है कि यद्यपि आपको केवल इकाई के कुछ गुणों की आवश्यकता है, फिर भी ओआरएम ढांचे द्वारा उत्पन्न चयन क्वेरी पूरी इकाई को अपनी पूरी महिमा में लाएगी। दूसरी ओर एक दृश्य, हालांकि ओआरएम ढांचे के साथ एक इकाई के लिए मैप किया गया है, केवल आपको आवश्यक डेटा लाएगा।

दूसरा, चूंकि ओआरएम नक्शा इकाइयों को टेबल पर ढांचे के रूप में बनाता है, क्लाइंट पक्ष पर इकाइयों के बीच संबंध उत्पन्न होते हैं (और हाइड्रेटेड), जिसका अर्थ है कि क्वेरी को निष्पादित करना होगा और उन इकाइयों को जोड़ने से पहले ऐप पर वापस जाना होगा, रनटाइम पर हो सकता है अप्प।

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

प्वाइंट यह है कि विचार ओआरएम का उपयोग कर ऐप्स के लिए जीवन बचतकर्ता हैं। विकल्प मैन्युअल रूप से डीबी कॉल करना है, और परिणामी रिकॉर्डसेट को मैन्युअल इकाइयों/मॉडलों में मैन्युअल रूप से पास करना है।

हालांकि यह दृष्टिकोण अच्छा है और निश्चित रूप से परिणाम उत्पन्न करता है, इसमें बहुत से नकारात्मक पहलू हैं। मैनुअल कोड ... मैनुअल है; बनाए रखने के लिए कड़ी मेहनत, कार्यान्वयन में बोझिल, और डीवी प्रदाता एपीआई के तार्किक डोमेन मॉडल बनाम विनिर्देशों के बारे में अधिक चिंता करने के लिए देवताओं का कारण बनता है। उल्लेख नहीं है कि यह विकास, रखरखाव, बग के सतह क्षेत्र आदि के लिए लागत (इसकी बहुत अधिक श्रमिक) लागत बढ़ाता है

तो किसी के भी विचार कहने के लिए बुरा है, कृपया चीजों के दूसरी तरफ विचार करें; उच्च और शक्तिशाली डीबीए की सामग्री के बारे में अक्सर कोई सुराग नहीं है।

संबंधित मुद्दे