में दृश्यों का उपयोग करना मेरे पास एक आधार तालिका से बनाया गया एक दृश्य है। यह दृश्य मूल रूप से किसी भी फ़िल्टर परिस्थितियों के बिना तालिका की सटीक प्रति है और इसमें तालिका के सभी कॉलम और रिकॉर्ड हैं।एसक्यूएल
क्या मेरे आवेदन या संग्रहीत प्रक्रियाओं में सीधे तालिका के बजाय दृश्य (जो तालिका की सीधी प्रति है) का उपयोग करने में कोई फायदा है।
इस मामले में दृश्य और तालिका के बीच कोई अंतर नहीं है। देखें तालिका की प्रति नहीं है लेकिन संग्रहित चयन कथन की तरह कुछ है।
प्रदर्शन दृष्टिकोण से इस दृष्टिकोण के गंभीर नुकसान हो सकते हैं।
http://www.sql-server-performance.com/tips/views_general_p1.aspx
मैं यदि संभव हो तो विचारों का उपयोग न करें सुझाव है।
जैसा कि संदर्भित आलेख की टिप्पणियों में उल्लेख किया गया है, तथ्य की तुलना में अधिक गलत जानकारी है, और मैं पोस्टर से सहमत हूं कि लेख को हटाया जाना चाहिए। अटकलें और यहां कहें कि अनुभवजन्य साक्ष्य के लिए कोई विकल्प नहीं है जो आलेख प्रदान नहीं करता है। –
नहीं।
अनुक्रमित विचारों के अपवाद के साथ, दृश्य केवल एसक्यूएल क्लीनर को पढ़ने के लिए वास्तव में उपयोगी होते हैं - दृश्य युक्त क्वेरी निष्पादित करना आवश्यक रूप से क्वेरी में कॉपी और चिपकाए गए व्यू परिभाषा के साथ एक क्वेरी निष्पादित करने जैसा ही होता है।
मैं इस तरह से जटिल विचारों के उपयोग को हतोत्साहित करता हूं, हालांकि यह क्वेरी साफ़ क्लीनर बनाता है, यह निदान प्रक्रिया को अधिक दर्द देता है (जैसा कि आपको मूल प्रश्नों को समझने के लिए सभी विचारों को देखने की आवश्यकता है कर रहा है)
लेकिन आपको जागरूक होने की आवश्यकता है कि विचारों का तरीका थोड़ा अलग है, क्योंकि आप डीबी पक्ष पर कुछ ओवरकिल करते हैं।
एक दृश्य जिस तरह से काम करता है, एक चयन * कर रहा है, और फिर उस कॉलम के लिए खुद को फ़िल्टर कर रहा है जिसे आप इसमें जोड़ रहे हैं।
मैं इसके लिए विचारों का उपयोग करने के लिए वास्तव में थके हुए नहीं हूं, जब तक कि कुछ गंभीर सुरक्षा चिंताएं न हों।
जाने का तरीका एक संग्रहित प्रक्रिया बनाना है जो सीधे तालिका से डेटा पकड़ लेता है। इस तरह, आप अधिकतम इंडेक्स और वह सब ले सकते हैं।
चीयर्स
वहाँ एक तत्काल उद्देश्य या लाभ नहीं हो सकता है, लेकिन यह अमूर्त का एक बिंदु है जो समय में बाद में किसी समय एक वास्तुशिल्प या सुरक्षा आधारित लाभ प्रदान कर सकते हैं के साथ आप प्रदान करता है।
दृश्य को संक्षेप में डेटा अनुबंध माना जा सकता है, जो भविष्य में अंतर्निहित संरचना को एक बिंदु तक फ्लेक्स करने की अनुमति देता है, बाहरी दुनिया को इसे महसूस करने के बिना।
सुरक्षा पक्ष पर, भविष्य में एक बिंदु पर जहां एक खंड डाला जा सकता है, जो आपको पंक्ति स्तर फ़िल्टरिंग/सुरक्षा प्रदान करना शुरू करता है, जहां तालिका में सीधी पहुंच किसी भी भविष्य के कदम को रोकती है।
एक लाभ (या आपके दृष्टिकोण के आधार पर नुकसान) यह है कि दृश्य आपको अपने कोड के बजाय SQL सर्वर के भीतर व्यावसायिक तर्क संग्रहीत करने की अनुमति देते हैं। यदि आपको अपने कोड को पुन: सम्मिलित किए बिना आसानी से व्यवसाय को बदलने की आवश्यकता है, तो दृश्य को संशोधित करना ऐसा करने का एक तेज़ और आसान तरीका है।
मैं व्यक्तिगत रूप से आवेदन तथापि कोड :)
दृश्य पल में भौतिक परत (टेबल) आपके मामले में ऊपर एक तार्किक परत के रूप में के बारे में सोचा जा सकता है कि परत है में परिभाषित के व्यापार तर्क होने पसंद करते हैं इतना पतला इसके मूल्य पर सवाल उठाया जा सकता है। हालांकि समय के साथ, ऐसा मामला नहीं हो सकता है। तालिका तक पहुंचने के लिए एक दृश्य का उपयोग करके, आपको लगभग कुछ भी लागत नहीं है, फिर भी संभवतः भौतिक मॉडल में संभावित परिवर्तनों से आपके कोड को इन्सुलेट करता है।
इस दृष्टिकोण के प्रदर्शन और रखरखाव के मामले में लागत है। ओआरएम परत या संग्रहीत प्रक्रिया में अवशोषण कोडबेस को भौतिक मॉडल में परिवर्तन से अपनाने के लिए पर्याप्त होना चाहिए। –
@ इयान: सब कुछ एक लागत है; सवाल यह है कि अगर यह लाभ से अधिक है। मैंने कोई विश्वसनीय अध्ययन नहीं पढ़ा है जो प्रदर्शन दर्द बिंदु के रूप में विचारों की पहचान करता है। निश्चित रूप से एक एपीआई का अनुचित उपयोग सर्वर को घुटनों पर ला सकता है - लेकिन यह शायद ही एपीआई की गलती है। –
हाय औसत, यदि इनमें से कोई भी उत्तर उपयोगी रहा है, तो कृपया उनमें से एक को स्वीकार्य मानने पर विचार करें। इसे अच्छे शिष्टाचार माना जाता है और भविष्य में दूसरों को आपके सवालों के जवाब देने के लिए प्रोत्साहित करता है। :) –