एसक्यूएल सर्वर दृश्यों का उपयोग करने के डाउनसाइड्स क्या हैं?

Question

एसक्यूएल सर्वर दृश्यों का उपयोग करने के डाउनसाइड्स क्या हैं?

मैं अपने डेटा को एक denormalized रूप में दिखाने के लिए अक्सर विचार बनाते हैं।

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

लेकिन क्या इन विचारों को बनाने और उपयोग करने की कोई कीमत है?

क्या मैं क्वेरी प्रसंस्करण धीमा कर रहा हूं (या तेज़ हो रहा हूं?) क्वेरी प्रसंस्करण?

Answer 1

जब दृश्यों की बात आती है तो फायदे और नुकसान होते हैं।

लाभ:

1. वे आभासी मेज और एक अलग वस्तु के रूप में डेटाबेस में संग्रहीत नहीं हैं। जो कुछ संग्रहीत है वह चयन कथन है।
2. इसे उपयोगकर्ता द्वारा देखे जा सकने वाले प्रतिबंध को प्रतिबंधित करके सुरक्षा उपाय के रूप में उपयोग किया जा सकता है।
3. यह आमतौर पर जटिल दृश्य क्वेरी को एक दृश्य में encapsulating द्वारा पढ़ने के लिए आसान बना सकते हैं। हालांकि यह एक डबल तलवार वाली तलवार है - नुकसान # 3 देखें।

नुकसान:

1. यह एक संग्रहीत प्रक्रिया के रूप में के रूप में तेजी से कैश की गई तो यह नहीं होगा एक अनुकूलित कार्य योजना लागू नहीं है।
2. चूंकि यह मूल रूप से केवल एक चयन का एक अमूर्त है, यह शुद्ध चयन करने से थोड़ा धीमा है।
3. यह जटिलता को छुपा सकता है और गॉथस का नेतृत्व कर सकता है। (गोटो: सम्मानित नहीं किया गया आदेश)।

मेरी व्यक्तिगत राय दृश्यों का उपयोग नहीं करना है बल्कि बदले में प्रक्रियाओं का उपयोग करना है क्योंकि वे सुरक्षा और दृश्यों को समाहित करते हैं लेकिन बेहतर प्रदर्शन के साथ भी आते हैं।

Answer 2

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

SQL सर्वर में आप create materialized or indexed views (SQL Server 2000 से) भी कर सकते हैं, जो गति को कुछ हद तक बढ़ाता है।

Answer 3

मैं नियमित रूप से विचारों का भी उपयोग करता हूं। हालांकि, ध्यान देने योग्य बात यह है कि यदि आपकी अंतर्निहित तालिकाओं में अक्सर परिवर्तन होता है (विशेष रूप से विकास के दौरान) तो बहुत से विचारों का उपयोग करना मुश्किल हो सकता है।

संपादित करें: यह कहकर, मुझे रखरखाव के मुद्दे से अधिक जटिल प्रश्नों को सरल बनाने और पुन: उपयोग करने में सक्षम होने की सुविधा और लाभ मिलता है, खासकर अगर विचारों को जिम्मेदारी से उपयोग किया जाता है।

Answer 4

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

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

Answer 5

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

अपने विचारों का सम्मान करें, और वे आपको अच्छी तरह से इलाज करेंगे।

Answer 6

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

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

Answer 7

दृश्य प्रदर्शन के लिए हानि हो सकता है जब दृश्य में तर्क, कॉलम, पंक्तियां या सारणी होती हैं जो अंततः आपकी अंतिम क्वेरी द्वारा उपयोग नहीं की जाती हैं। मैं आपको बता नहीं सकता कि कितनी बार मैं जैसे सामान को देखा है:

SELECT ... 
FROM (View with complex UNION of ActiveCustomer and InactiveCustomer tables) 
WHERE Active = True 

, या

SELECT (one column) 
FROM (view that returns 50 columns) 

(इस प्रकार सभी पंक्तियां InactiveCustomer मेज से देखने में शामिल थे को छान) (SQL डेटा कि बाद में किसी कदम पर त्याग दिया जाता है की बहुत सारी पुनः प्राप्त करने की है। इसके संभव उन अन्य स्तंभों को पुनः प्राप्त करने महंगा, एक बुकमार्क देखने के माध्यम से की तरह) कर रहे हैं, या

SELECT ... 
FROM (view with complex filters) 
WHERE (entirely different filters) 

(इसकी संभावना एसक्यूएल हो सकता है एक और अधिक उचित सूचकांक अगर टेबल सीधे पूछे गए थे), या

SELECT (only fields from a single table) 
FROM (view that contains crazy complex joins) 

(में शामिल होने के माध्यम से सीपीयू भूमि के ऊपर के बहुत सारे, और अनावश्यक आईओ इस्तेमाल किया तालिका के लिए पढ़ता है बाद में उन्हें छोड़ दिया जाता है कि), या मेरी पसंदीदा:

SELECT ... 
FROM (Crazy UNION of 12 tables each containing a month of data) 
WHERE OrderDate = @OrderDate 

(12 टेबल पढ़ता है जब इसे केवल पढ़ने की आवश्यकता होती है 1)।

में मामलों में, एसक्यूएल "कवर के माध्यम से देखने" के लिए पर्याप्त स्मार्ट है और वैसे भी एक प्रभावी क्वेरी योजना के साथ आता है। लेकिन अन्य मामलों में (विशेष रूप से बहुत ही जटिल), यह नहीं कर सकता है। उपर्युक्त स्थितियों में से प्रत्येक में, जवाब को हटाने और इसके बजाय अंतर्निहित तालिकाओं को क्वेरी करना था।

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

Answer 8

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

http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/ (सीमा # 1 आदेश के बारे में द्वारा :-) है

Answer 9

क्या एसक्यूएल सर्वर में दृश्य के विभिन्न सीमाओं कर रहे हैं?

दृश्य के शीर्ष 11 सीमाएं

• दृश्य COUNT () समर्थन नहीं करते; तथापि, यह COUNT_BIG समर्थन कर सकते हैं ()
• आदेश BY खंड देखें में काम नहीं करता
• नियमित प्रश्न या संग्रहित प्रक्रियाओं हमें लचीलापन देने के जब हम एक और स्तंभ की जरूरत है; हम तुरंत नियमित प्रश्नों के लिए एक कॉलम जोड़ सकते हैं। यदि हम दृश्यों के साथ ऐसा करना चाहते हैं, तो हमें उन्हें पहले
• पर प्रदर्शित इंडेक्स को देखा गया है जो अक्सर इस्तेमाल नहीं किया गया है
• एक बार दृश्य बनाया गया है और यदि मूल तालिका में कोई कॉलम जोड़ा गया है या हटा दिया गया है, तो यह है आमतौर पर देखने में परिलक्षित नहीं है जब तक यह ताजा है
• यूनिअन ऑपरेशन इंडेक्स्ड देखें में अनुमति नहीं है
• हम एक नेस्टेड दृश्य की स्थिति पर एक सूचकांक नहीं बना सकते मतलब है कि हम एक दृश्य जो एक और दृश्य से बनाया गया है पर सूचकांक नहीं बना सकते।
• स्व इंडेक्स्ड दृश्य में अनुमति नहीं शामिल होने के
• बाहरी इंडेक्स्ड दृश्य में अनुमति नहीं शामिल हों
• क्रॉस डेटाबेस प्रश्नों इंडेक्स्ड दृश्य में अनुमति नहीं

स्रोत एसक्यूएल एमवीपी पिनाल डेव

http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/

Answer 10

निम्नलिखित एक एसक्यूएल हैक है जो किसी ऑर्डर को संदर्भ में संदर्भित करने की अनुमति देता है:

create view toto1 as 
select top 99.9999 percent F1 
from Db1.dbo.T1 as a 
order by 1 

लेकिन मेरी प्राथमिकता Row_Number उपयोग करने के लिए है:

create view toto2 as 
select *, ROW_NUMBER() over (order by [F1]) as RowN from ( 
select f1 
from Db1.dbo.T1) as a