कब और क्यों कुछ तय करता है कि उन्हें अपने डेटाबेस में एक दृश्य बनाने की आवश्यकता है? क्यों न केवल एक सामान्य संग्रहित प्रक्रिया चलाएं या चयन करें?
जवाबों:
एक दृश्य कई लाभ प्रदान करता है।
1. दृश्य जटिलता को छिपा सकते हैं
यदि आपके पास एक क्वेरी है जिसमें कई तालिकाओं में शामिल होने की आवश्यकता है, या आपके पास जटिल तर्क या गणना है, तो आप उस तर्क को एक दृश्य में कोड कर सकते हैं, फिर दृश्य से उसी तरह का चयन करें जैसे आप एक तालिका में करेंगे।
2. दृश्यों का उपयोग सुरक्षा तंत्र के रूप में किया जा सकता है
एक दृश्य एक तालिका (या तालिकाओं) से कुछ कॉलम और / या पंक्तियों का चयन कर सकता है, और अंतर्निहित तालिकाओं के बजाय दृश्य पर सेट अनुमतियाँ। यह केवल उस डेटा को सरफेस करने की अनुमति देता है जो किसी उपयोगकर्ता को देखने की आवश्यकता होती है।
3. दृश्य सहायक विरासत कोड को सरल बना सकते हैं
यदि आपको एक तालिका को फिर से बनाने की आवश्यकता है जो बहुत सारे कोड को तोड़ देगा, तो आप तालिका को उसी नाम के दृश्य के साथ बदल सकते हैं। दृश्य मूल तालिका के समान सटीक स्कीमा प्रदान करता है, जबकि वास्तविक स्कीमा बदल गया है। यह विरासत कोड को रखता है जो तालिका को तोड़ने से संदर्भित करता है, जिससे आप अपने अवकाश पर विरासत कोड को बदल सकते हैं।
ये कई उदाहरणों में से कुछ हैं कि कैसे दृश्य उपयोगी हो सकते हैं।
अन्य चीजों के अलावा, इसका इस्तेमाल सुरक्षा के लिए किया जा सकता है। यदि आपके पास "ग्राहक" तालिका है, तो आप अपनी बिक्री के सभी लोगों को नाम, पता, ज़िपकोड आदि क्षेत्रों तक पहुंच देना चाहते हैं, लेकिन credit_card_number नहीं कर सकते। आप एक ऐसा दृश्य बना सकते हैं जिसमें केवल वे कॉलम शामिल हैं जिनकी उन्हें एक्सेस की आवश्यकता है और फिर उन्हें दृश्य पर एक्सेस प्रदान करें।
Select name, address, zipcode from customerके बजाय उद्देश्य की सेवा नहीं करेगा creating a view?
select * from customerजो उन्हें हर चीज तक पहुंच प्रदान करता है। यदि आप उन्हें दृश्य तक पहुँच देते हैं और तालिका नहीं, तो वे उन फ़ील्ड तक नहीं पहुँच सकते जो दृश्य में नहीं हैं।
एक दृश्य एक क्वेरी का एक एनकैप्सुलेशन है। विचारों में तब्दील होने वाली क्वेरी जटिल होती हैं और पुन: उपयोग के लिए दृश्य के रूप में उन्हें सहेजना लाभप्रद हो सकता है।
मैं आमतौर पर रिपोर्टिंग उद्देश्यों के लिए अक्सर उपयोग किए जाने वाले डेटा को सामान्य करने और / या एकत्र करने के लिए दृश्य बनाता हूं।
संपादित करें
विस्तार के माध्यम से, अगर मेरे पास एक डेटाबेस था जिसमें कुछ संस्थाएं व्यक्ति, कंपनी, भूमिका, मालिक प्रकार, आदेश, आदेश विस्तार, पता और फोन थीं, जहां व्यक्ति तालिका कर्मचारियों और संपर्कों और पते दोनों को संग्रहीत करती है फोन टेबल दोनों व्यक्तियों और कंपनियों के लिए फोन नंबर संग्रहीत करते हैं, और विकास टीम को रिपोर्ट तैयार करने (या गैर-डेवलपर्स के लिए रिपोर्टिंग डेटा सुलभ बनाने) के साथ सौंपा गया था, जैसे कि कर्मचारी द्वारा बिक्री, या ग्राहक द्वारा बिक्री, या क्षेत्र द्वारा बिक्री, महीने द्वारा बिक्री। , राज्य द्वारा, आदि। मैं उन विचारों का एक समूह बनाऊंगा जो डेटाबेस संस्थाओं के बीच संबंधों को सामान्यीकृत करते हैं ताकि वास्तविक विश्व संस्थाओं का अधिक एकीकृत दृश्य (कोई उद्देश्य न हो) उपलब्ध था। कुछ लाभों में शामिल हो सकते हैं:
कई कारण: यदि आपके पास जटिल जोड़ हैं, तो कभी-कभी एक दृश्य होना सबसे अच्छा होता है ताकि किसी भी पहुंच में हमेशा सही और डेवलपर्स शामिल न हों; उन्हें उन सभी तालिकाओं को याद रखना होगा जिनकी उन्हें आवश्यकता हो सकती है। आमतौर पर यह एक वित्तीय अनुप्रयोग के लिए हो सकता है जहां यह अत्यंत महत्वपूर्ण होगा कि सभी वित्तीय रिपोर्ट डेटा के एक ही सेट पर आधारित हों।
यदि आपके पास ऐसे उपयोगकर्ता हैं जिन्हें आप उन रिकॉर्ड्स को सीमित करना चाहते हैं जो वे कभी भी देख सकते हैं, तो आप एक दृश्य का उपयोग कर सकते हैं, उन्हें केवल अंतर्निहित तालिकाओं को देखने के लिए एक्सेस दे सकते हैं और फिर दृश्य को क्वेरी कर सकते हैं।
लगता है कि क्रिस्टल रिपोर्टें संग्रहीत प्रोक्स के विचारों का उपयोग करना पसंद करती हैं, इसलिए जो लोग बहुत अधिक रिपोर्ट लेखन करते हैं वे बहुत सारे विचारों का उपयोग करते हैं
डेटाबेस को रीफ़ैक्ट करने पर दृश्य भी बहुत उपयोगी होते हैं। आप अक्सर परिवर्तन को छिपा सकते हैं ताकि पुराने कोड इसे एक दृश्य बनाकर न देखें। यह देखने के लिए कि यह कैसे काम करता है, यह रिफ्लेक्टर करने के लिए एक बहुत शक्तिशाली तरीका है।
एक संग्रहीत प्रक्रिया पर एक दृश्य का एक प्रमुख लाभ यह है कि आप एक दृश्य का उपयोग कर सकते हैं जैसे आप एक तालिका का उपयोग करते हैं। अर्थात्, किसी दृश्य को सीधे FROMक्वेरी के खंड में संदर्भित किया जा सकता है । जैसे SELECT * FROM dbo.name_of_view,।
बस हर दूसरे तरीके के बारे में, संग्रहीत प्रक्रियाएं अधिक शक्तिशाली होती हैं। आप मानकों में पारित कर सकते हैं सहित out, पैरामीटर है कि आप प्रभावी रूप से एक बार में कई मान करने की अनुमति आप कर सकते हैं SELECT, INSERT, UPDATE, और DELETEऑपरेशन, इत्यादि आदि
यदि आप एक दृश्य को FROMक्लॉज़ के भीतर से क्वेरी करने की क्षमता चाहते हैं , लेकिन आप मापदंडों में भी पास होना चाहते हैं, तो ऐसा करने का एक तरीका भी है। इसे टेबल-वैल्यू फ़ंक्शन कहा जाता है।
यहाँ विषय पर एक बहुत उपयोगी लेख है:
संपादित करें: वैसे, इस तरह का सवाल उठता है, तालिका-मूल्यवान फ़ंक्शन पर किसी दृश्य का क्या फायदा होता है? मेरे पास उसके लिए वास्तव में अच्छा जवाब नहीं है, लेकिन मैं ध्यान दूंगा कि एक दृश्य बनाने के लिए टी-एसक्यूएल सिंटैक्स तालिका-मूल्यवान फ़ंक्शन की तुलना में सरल है, और आपके डेटाबेस के उपयोगकर्ता विचारों से अधिक परिचित हो सकते हैं।
यह आपके ORM और आपकी तालिकाओं के बीच एक अच्छे "मध्यम पुरुष" के रूप में कार्य कर सकता है।
उदाहरण:
हमारे पास एक व्यक्ति तालिका थी जिसे हमें उस पर संरचना को बदलने की आवश्यकता थी इसलिए स्तंभ SomeColumn को किसी अन्य तालिका में ले जाया जा रहा था और इसमें कई संबंधों के लिए एक होगा।
हालांकि, अधिकांश प्रणाली, व्यक्ति के संबंध में, अभी भी कुछ चीजों को नहीं बल्कि SomeColumn का उपयोग एक ही चीज के रूप में करती है। हमने सभी SomeColumns को एक साथ लाने के लिए एक दृश्य का उपयोग किया और इसे दृश्य में रखा, जिसने अच्छी तरह से काम किया।
यह काम किया क्योंकि डेटा लेयर बदल गई थी, लेकिन व्यावसायिक आवश्यकता मूलभूत रूप से नहीं बदली थी, इसलिए व्यावसायिक वस्तुओं को बदलने की आवश्यकता नहीं थी। यदि व्यावसायिक वस्तुओं को बदलना होता तो मुझे नहीं लगता कि यह एक व्यवहार्य समाधान होता, लेकिन विचार निश्चित रूप से एक अच्छे मध्य बिंदु के रूप में कार्य करते हैं।
विशिष्ट डेटा दृश्य पर ध्यान केंद्रित करने के लिए उपयोगकर्ताओं को उन विशिष्ट डेटा पर ध्यान केंद्रित करने की अनुमति देता है जो उनकी रुचि रखते हैं और उन विशिष्ट कार्यों पर जिनके लिए वे जिम्मेदार हैं। अनावश्यक डेटा को दृश्य से बाहर रखा जा सकता है। इससे डेटा की सुरक्षा भी बढ़ जाती है क्योंकि उपयोगकर्ता केवल उस डेटा को देख सकते हैं जो दृश्य में परिभाषित किया गया है न कि अंतर्निहित तालिका में डेटा। सुरक्षा उद्देश्यों के लिए विचारों का उपयोग करने के बारे में अधिक जानकारी के लिए, सुरक्षा तंत्र के रूप में दृश्य का उपयोग करना देखें।
डेटा हेरफेर को सरल बनाने के लिए उपयोगकर्ता डेटा में हेरफेर कैसे कर सकते हैं। आप बार-बार उपयोग किए जाने वाले जुड़ावों, अनुमानों, UNION क्वेरीज़ और सेलेक्ट क्वेरीज़ को विचारों के रूप में परिभाषित कर सकते हैं ताकि उपयोगकर्ताओं को उस डेटा पर हर बार एक अतिरिक्त ऑपरेशन करने पर सभी शर्तों और योग्यताओं को निर्दिष्ट न करना पड़े। उदाहरण के लिए, एक जटिल क्वेरी जिसका उपयोग रिपोर्टिंग उद्देश्यों के लिए किया जाता है और तालिका के समूह से डेटा पुनर्प्राप्त करने के लिए उपश्रेणी, बाहरी जुड़ाव और एकत्रीकरण करता है, एक दृश्य के रूप में बनाया जा सकता है। दृश्य डेटा तक पहुंच को सरल करता है क्योंकि अंतर्निहित क्वेरी को हर बार रिपोर्ट को लिखना या प्रस्तुत करना नहीं होता है; इसके बजाए दृश्य को दिखाया गया है। डेटा में हेरफेर के बारे में अधिक जानकारी के लिए।
आप इनलाइन उपयोगकर्ता-परिभाषित फ़ंक्शंस भी बना सकते हैं जो तार्किक रूप से पैरामीटर किए गए विचारों या उन विचारों के रूप में कार्य करते हैं जिनके पास WHERE- खंड खोज स्थितियों में पैरामीटर हैं। अधिक जानकारी के लिए, इनलाइन उपयोगकर्ता-परिभाषित कार्य देखें।
डेटा व्यू कस्टमाइज़ करने के लिए , विभिन्न उपयोगकर्ताओं को अलग-अलग तरीकों से डेटा देखने की अनुमति देता है, तब भी जब वे समान डेटा का समवर्ती उपयोग कर रहे हों। यह विशेष रूप से लाभप्रद है जब कई अलग-अलग रुचियों और कौशल स्तरों वाले उपयोगकर्ता एक ही डेटाबेस को साझा करते हैं। उदाहरण के लिए, एक दृश्य बनाया जा सकता है जो केवल उन ग्राहकों के लिए डेटा पुनर्प्राप्त करता है जिनके साथ एक खाता प्रबंधक सौदा करता है। दृश्य का उपयोग करने वाले खाता प्रबंधक की लॉगिन आईडी के आधार पर पुनर्प्राप्त करने के लिए कौन सा डेटा निर्धारित कर सकता है।
डेटा एक्सपोर्ट और इम्पोर्ट करने के लिए डेटा को दूसरे एप्लिकेशन में एक्सपोर्ट करने के लिए इस्तेमाल किया जा सकता है। उदाहरण के लिए, आप Microsoft® Excel का उपयोग करके बिक्री डेटा का विश्लेषण करने के लिए पब डेटाबेस में स्टोर और बिक्री तालिकाओं का उपयोग करना चाह सकते हैं। ऐसा करने के लिए, आप स्टोर और बिक्री तालिकाओं के आधार पर एक दृश्य बना सकते हैं। फिर आप दृश्य द्वारा परिभाषित डेटा को निर्यात करने के लिए bcp उपयोगिता का उपयोग कर सकते हैं। डेटा को bcp यूटिलिटी या BULK INSERT स्टेटमेंट का उपयोग करके डेटा फ़ाइलों से कुछ दृश्यों में आयात किया जा सकता है, बशर्ते कि INSERT स्टेटमेंट का उपयोग करके पंक्तियों को व्यू में डाला जा सकता है। डेटा को विचारों में कॉपी करने के प्रतिबंध के बारे में अधिक जानकारी के लिए, INSERT देखें। डेटा को कॉपी और देखने के लिए bcp उपयोगिता और BULK INSERT स्टेटमेंट का उपयोग करने के बारे में अधिक जानकारी के लिए, एक दृश्य से प्रतिलिपि बनाना या देखना।
विभाजन डेटा को संयोजित करने के लिए Transact-SQL UNION सेट ऑपरेटर को एक ही परिणाम सेट में अलग-अलग तालिकाओं से दो या अधिक प्रश्नों के परिणामों को संयोजित करने के लिए एक दृश्य के भीतर उपयोग किया जा सकता है। यह उपयोगकर्ता को एक एकल तालिका के रूप में दिखाई देता है जिसे विभाजन दृश्य कहा जाता है। उदाहरण के लिए, यदि एक तालिका में वाशिंगटन के लिए बिक्री डेटा शामिल है, और दूसरी तालिका में कैलिफोर्निया के लिए बिक्री डेटा शामिल है, तो उन तालिकाओं के यूनिअन से एक दृश्य बनाया जा सकता है। दृश्य दोनों क्षेत्रों के लिए बिक्री डेटा का प्रतिनिधित्व करता है। विभाजन किए गए दृश्यों का उपयोग करने के लिए, आप कई समान तालिकाओं का निर्माण करते हैं, प्रत्येक तालिका में जोड़े जा सकने वाले डेटा की सीमा निर्धारित करने के लिए एक बाधा निर्दिष्ट करते हैं। फिर इन बेस टेबल का उपयोग करके दृश्य बनाया जाता है। जब दृश्य क्वेरी की जाती है, तो SQL सर्वर स्वचालित रूप से निर्धारित करता है कि कौन सी तालिकाएँ क्वेरी से प्रभावित होती हैं और केवल उन तालिकाओं को संदर्भित करती हैं। उदाहरण के लिए, यदि कोई क्वेरी निर्दिष्ट करता है कि केवल वाशिंगटन राज्य के लिए बिक्री डेटा आवश्यक है, तो SQL सर्वर केवल वाशिंगटन बिक्री डेटा वाले तालिका को पढ़ता है; कोई अन्य तालिकाएँ एक्सेस नहीं की गई हैं।
विभाजन के विचार एक ही डेटाबेस में तालिकाओं के रूप में दूरस्थ सर्वर जैसे कई विषम स्रोतों के डेटा पर आधारित हो सकते हैं। उदाहरण के लिए, विभिन्न दूरस्थ सर्वरों से डेटा को संयोजित करने के लिए, जिनमें से प्रत्येक आपके संगठन के भिन्न क्षेत्र के लिए डेटा संग्रहीत करता है, आप वितरित क्वेरी बना सकते हैं जो प्रत्येक डेटा स्रोत से डेटा पुनर्प्राप्त करते हैं, और फिर उन वितरित प्रश्नों के आधार पर एक दृश्य बनाते हैं। कोई भी क्वेरी दूरस्थ सर्वर पर तालिका से केवल डेटा पढ़ता है जिसमें क्वेरी द्वारा अनुरोधित डेटा होता है; दृश्य में वितरित प्रश्नों द्वारा संदर्भित अन्य सर्वरों तक पहुंच नहीं है।
जब आप कई तालिकाओं या कई सर्वरों में डेटा को विभाजित करते हैं, तो डेटा के केवल कुछ अंश तक पहुंचने वाले प्रश्न तेजी से चल सकते हैं क्योंकि स्कैन करने के लिए कम डेटा होता है। यदि टेबल अलग-अलग सर्वरों पर, या कई प्रोसेसर वाले कंप्यूटर पर स्थित हैं, तो क्वेरी में शामिल प्रत्येक तालिका को समानांतर में भी स्कैन किया जा सकता है, जिससे क्वेरी प्रदर्शन में सुधार होगा। इसके अतिरिक्त, अनुरक्षण कार्य, जैसे कि अनुक्रमणिका का पुनर्निर्माण करना या तालिका का बैकअप लेना, अधिक तेज़ी से निष्पादित कर सकते हैं। एक विभाजन दृश्य का उपयोग करके, डेटा अभी भी एक ही तालिका के रूप में प्रकट होता है और मैन्युअल रूप से सही अंतर्निहित तालिका को संदर्भित किए बिना इस तरह के रूप में देखा जा सकता है।
यदि इनमें से कोई भी शर्त पूरी हो जाती है, तो विभाजन किए गए दृश्य अपूरणीय होते हैं: INSERT, UPDATE और DELETE कथनों का समर्थन करने के लिए तर्क के साथ दृश्य पर एक INSTEAD ट्रिगर को परिभाषित किया गया है।
दोनों और INSERT, UPDATE और DELETE स्टेटमेंट्स अपडेटेड पार्टीशन के लिए परिभाषित नियमों का पालन करते हैं। अधिक जानकारी के लिए, एक विभाजन दृश्य बनाना देखें।
https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join
यहाँ दो सामान्य कारण हैं:
आप इसे सुरक्षा के लिए उपयोग कर सकते हैं। मुख्य टेबल पर कोई अनुमति न दें और ऐसे दृश्य बनाएं जो स्तंभ या पंक्ति पहुंच को सीमित करते हैं और उपयोगकर्ताओं को दृश्य देखने की अनुमति देते हैं।
आप इसका उपयोग सुविधा के लिए कर सकते हैं। कुछ तालिकाओं को एक साथ मिलाएं जिन्हें आप हर समय दृश्य में एक साथ उपयोग करते हैं। यह प्रश्नों को सुसंगत और आसान बना सकता है।
ऐसा करने का एक से अधिक कारण है। कभी-कभी सामान्य जुड़ाव प्रश्नों को आसान बना देता है क्योंकि सभी जोड़ को करने के बजाय एक तालिका नाम को क्वेरी कर सकता है।
एक अन्य कारण विभिन्न उपयोगकर्ताओं के लिए डेटा को सीमित करना है। उदाहरण के लिए:
Table1: Colums - USER_ID; USERNAME; SSN
व्यवस्थापक उपयोगकर्ताओं के वास्तविक टेबल पर निजी हो सकते हैं, लेकिन जिन उपयोगकर्ताओं को आप SSN कहने के लिए एक्सेस नहीं करना चाहते हैं, आप एक दृश्य बनाते हैं
उपयोगकर्ता का चयन करें, तालिका 1 से उपयोगकर्ता नाम के रूप में उपयोग देखें;
फिर उन्हें व्यू को एक्सेस करने के लिए प्राइवेट देते हैं न कि टेबल।
जब लीगेसी डेटाबेस पर रिपोर्टिंग करते हैं तो दृश्य एक देवी-देवता हो सकते हैं। विशेष रूप से, आप क्रिप्टिक 5 अक्षर नामों (जहां उनमें से 2 एक सामान्य उपसर्ग हैं!), या स्तंभ नाम से भरे हुए संक्षिप्त नाम के बजाय कामुक तालिका नामों का उपयोग कर सकते हैं, जो मुझे यकीन है कि उस समय समझ में आया होगा।
आम तौर पर मैं जीवन को आसान बनाने के लिए विचारों के साथ जाता हूं, कुछ इकाई से विस्तारित विवरण प्राप्त करता हूं जो कई तालिकाओं में संग्रहीत होता है (पठनीयता बढ़ाने के लिए कोड में बहुत सारे जोड़ हटाएं) और कभी-कभी कई डेटाबेस पर डेटा साझा करने के लिए या यहां तक कि आवेषण को पढ़ने में आसान बनाने के लिए।
तालिका में उपयोगकर्ता द्वारा अद्यतन किए जा सकने वाले स्तंभों को सीमित करने के लिए अनुमतियों के साथ-साथ दृश्य का उपयोग कैसे करें
/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;
/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1जब मैं किसी तालिका (नों) का स्नैपशॉट देखना चाहता हूं, और / या दृश्य (केवल पढ़ने के लिए)
मैं संग्रहीत प्रक्रियाओं पर विचारों का उपयोग करना पसंद करता हूं, जब मैं केवल एक क्वेरी चला रहा हूं। दृश्य सुरक्षा को भी सरल कर सकते हैं, कई तालिकाओं में आवेषण / अपडेट को कम करने के लिए उपयोग किया जा सकता है और इसका उपयोग डेटा को स्नैपशॉट / भौतिक करने के लिए किया जा सकता है (लंबे समय तक चलने वाली क्वेरी चलाएं, और परिणामों को कैश्ड रखें)।
मैंने लंबे समय तक चलने वाले प्रश्नों के लिए भौतिक विचारों का उपयोग किया है जिन्हें वास्तविक समय में सटीक रखने की आवश्यकता नहीं है।
यह आपके प्रश्न का सटीक उत्तर नहीं देता है, लेकिन मैंने सोचा कि यह भौतिकवादी दृश्यों का उल्लेख करने लायक होगा । मेरा अनुभव ज्यादातर ओरेकल के साथ है लेकिन माना जाता है कि SQL- सर्वर काफी समान है।
हमने XML प्रदर्शन समस्याओं को दूर करने के लिए अपनी वास्तुकला में कुछ इसी तरह का उपयोग किया। हमारे सिस्टम को एक पंक्ति में XML के रूप में संग्रहीत बहुत सारे डेटा के साथ डिज़ाइन किया गया है और अनुप्रयोगों को इसके भीतर विशेष मूल्यों को क्वेरी करने की आवश्यकता हो सकती है। XMLTypes के बहुत से हैंडल करने और बड़ी संख्या में पंक्तियों में XPaths को चलाने से प्रदर्शन पर बहुत अधिक प्रभाव पड़ता है इसलिए हम वांछित XML नोड्स को एक रिलेशनल टेबल में बाहर निकालने के लिए किसी भी प्रकार के भौतिक विचारों का उपयोग करते हैं, कभी भी बेस टेबल में परिवर्तन होता है। यह प्रभावी ढंग से मानक बिंदुओं के विपरीत एक समय में क्वेरी का भौतिक स्नैपशॉट प्रदान करता है जो मांग पर उनकी क्वेरी चलाएगा।
मैं एक संग्रहीत प्रक्रिया को एक विधि के रूप में अधिक देखता हूं जिसे मैं अपने डेटा के खिलाफ कॉल कर सकता हूं, जबकि मेरे लिए एक दृश्य आधार डेटा का सिंथेटिक संस्करण बनाने के लिए एक तंत्र प्रदान करता है जिसके खिलाफ प्रश्न या संग्रहीत प्रक्रियाएं बनाई जा सकती हैं। जब सरलीकरण या एकत्रीकरण समझ में आता है तो मैं एक दृश्य बनाऊंगा। जब मैं एक बहुत विशिष्ट सेवा प्रदान करना चाहता हूं तो मैं एक संग्रहीत प्रक्रिया लिखूंगा।
विचारों के बारे में एक जिज्ञासु बात यह है कि वे Microsoft Access द्वारा तालिकाओं के रूप में देखे जाते हैं: जब आप ODBC का उपयोग करते हुए SQL डेटाबेस में Microsoft Access फ्रंट-एंड संलग्न करते हैं, तो आप उपलब्ध तालिकाओं की सूची में तालिकाओं और विचारों को देखते हैं। इसलिए यदि आप MS Access में जटिल रिपोर्ट तैयार कर रहे हैं, तो आप SQL सर्वर को ज्वाइनिंग और क्वेरी कर सकते हैं, और आपके जीवन को बहुत सरल बना सकते हैं। एमएस एक्सेल में एक क्वेरी तैयार करने के लिए डिट्टो।
मेरे पास अपने उत्पादन डेटाबेस में केवल 10 या अधिक दृश्य हैं। मैं उन सभी स्तंभों के लिए उपयोग करता हूं जिनका मैं हर समय उपयोग करता हूं। मेरे द्वारा उपयोग किया जाने वाला एक सेट 7 तालिकाओं से आता है, कुछ बाहरी जोड़ के साथ और फिर से लिखने के बजाय कि मुझे केवल उस दृश्य को एक चयन में कॉल करना है और एक या 2 जोड़ बनाना है। मेरे लिए यह सिर्फ समय बचाने वाला है।
मैं xxx बना रहा हूं जो एक मुख्य तालिका (जैसे उत्पाद तालिका) और संदर्भ तालिका (जैसे ProductType या ProductDescriptionByLanguage) के बीच के सभी रिश्तों को मैप करता है। यह एक ऐसा दृश्य बनाएगा जो मुझे एक उत्पाद को पुनः प्राप्त करने की अनुमति देगा और यह सभी विदेशी कुंजी से इसके विवरण में अनुवादित विवरण है। फिर मैं आसानी से ग्रिड, कॉम्बो बॉक्स इत्यादि बनाने के लिए ऑब्जेक्ट बनाने के लिए ORM का उपयोग कर सकता हूं।
इसे अपने डेटाबेस स्कीमा को फिर से तैयार करने के रूप में सोचें।
मुझे लगता है कि पहले एक। प्रश्न की जटिलता को छिपाएं। विचारों के लिए इसका बहुत उपयुक्त है। जब हम डेटाबेस तालिकाओं को सामान्य करते हैं, तो बढ़ता है। जब तालिका की संख्या बढ़ जाती है, तो डेटा प्राप्त करना बहुत कठिन होता है। हैंडल करने का सबसे अच्छा तरीका विचारों का पालन करना है। अगर मैं गलत हूं तो मुझे सही करें।
हम एक तालिका में सभी पंक्तियों / स्तंभ तक पहुँचने से सीमा या पुनर्विचार करने के लिए दृश्य बनाते हैं। यदि मालिक चाहता है कि केवल विशिष्ट या सीमित पंक्तियों / स्तंभ को साझा करने की आवश्यकता है, तो वह उन स्तंभों के साथ एक दृश्य बनाएगा।
सुरक्षा के लिए: प्रत्येक उपयोगकर्ता को डेटाबेस तक पहुँचने के लिए केवल उन विचारों के एक छोटे से सेट के माध्यम से अनुमति देता है जिसमें उपयोगकर्ता या उपयोगकर्ता का विशिष्ट डेटा होता है जो उपयोगकर्ता को अन्य डेटा तक पहुँच को देखने, प्रतिबंधित करने के लिए अधिकृत होता है।
प्रश्नों और संरचना के लिए सरलता : एक दृश्य कई तालिकाओं से डेटा खींच सकता है और एकल तालिका प्रस्तुत कर सकता है, जानकारी को सरल बना सकता है और एक दृश्य के लिए एकल-तालिका प्रश्नों में बहु-तालिका क्वेरी को बदल सकता है और यह उपयोगकर्ताओं को डेटाबेस संरचना का एक विशिष्ट दृश्य प्रस्तुत करता है। विशिष्ट उपयोगकर्ताओं या उपयोगकर्ताओं के समूहों के लिए वर्चुअल टेबल का एक सेट के रूप में डेटाबेस।
सुसंगत डेटाबेस संरचना बनाने के लिए : दृश्य डेटाबेस संरचना की एक सुसंगत, अपरिवर्तित छवि प्रस्तुत करता है, भले ही अंतर्निहित स्रोत तालिकाओं को बदल दिया जाए।