डेटाबेस में लिखने और पढ़ने को संतुलित करना

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

इस लेख में, मैं दिखाऊंगा कि कैसे यह अवधारणा आपको ऑपरेटिंग लॉजिक में किसी भी बदलाव के बिना डेटाबेस में लिखने और पढ़ने को जल्दी और आसानी से संतुलित करने की अनुमति देती है। इसी तरह की कार्यक्षमता को आधुनिक वाणिज्यिक DBMS (विशेष रूप से, Oracle और Microsoft SQL सर्वर) में लागू करने का प्रयास किया गया है। लेख के अंत में मैं दिखाऊंगा कि उन्होंने जो किया, उसे हल्के ढंग से कहें तो, बहुत अच्छा काम नहीं किया।

विवरण

पहले की तरह, बेहतर समझ के लिए मैं उदाहरणों के साथ विवरण शुरू करूँगा। मान लीजिए कि हमें उस तर्क को लागू करने की आवश्यकता है जो विभागों की एक सूची लौटाएगा जिसमें उनमें कर्मचारियों की संख्या और उनका कुल वेतन होगा।

एक कार्यात्मक डेटाबेस में यह इस तरह दिखेगा:

CLASS Department ‘Отдел’;
name ‘Наименование’ = DATA STRING[100] (Department);

CLASS Employee ‘Сотрудник’;
department ‘Отдел’ = DATA Department (Employee);
salary ‘Зарплата’ =  DATA NUMERIC[10,2] (Employee);

countEmployees ‘Кол-во сотрудников’ (Department d) = 
    GROUP SUM 1 IF department(Employee e) = d;
salarySum ‘Суммарная зарплата’ (Department d) = 
    GROUP SUM salary(Employee e) IF department(e) = d;

SELECT name(Department d), countEmployees(d), salarySum(d);


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

यह स्पष्ट है कि विभिन्न DBMS में निष्पादन ओवरहेड भिन्न हो सकता है, लेकिन जटिलता किसी भी तरह से नहीं बदलेगी।

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

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

प्रतिबंध क्या हैं? केवल एक बात: ऐसे फ़ंक्शन में इनपुट मानों की एक सीमित संख्या होनी चाहिए जिसके लिए इसका मान परिभाषित किया गया है। अन्यथा, ऐसी तालिका बनाना असंभव होगा जो इसके सभी मानों को संग्रहीत करती हो, क्योंकि अनंत पंक्तियों वाली कोई तालिका नहीं हो सकती है।

उदाहरण:

employeesCount ‘Количество сотрудников с зарплатой > N’ (Department d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;


यह फ़ंक्शन N के अनंत मानों के लिए परिभाषित किया गया है (उदाहरण के लिए, कोई भी नकारात्मक मान उपयुक्त है)। इसलिए, आप इस पर MATERIALIZED नहीं डाल सकते। तो यह एक तार्किक सीमा है, तकनीकी नहीं (अर्थात इसलिए नहीं कि हम इसे लागू नहीं कर सके)। अन्यथा, कोई प्रतिबंध नहीं हैं. आप ग्रुपिंग, सॉर्टिंग, AND और OR, पार्टिशन, रिकर्सन आदि का उपयोग कर सकते हैं।

उदाहरण के लिए, पिछले आलेख की समस्या 2.2 में, आप दोनों कार्यों पर MATERIALIZED डाल सकते हैं:

bought 'Купил' (Customer c, Product p, INTEGER y) = 
    GROUP SUM sum(Detail d) IF 
        customer(order(d)) = c AND 
        product(d) = p AND 
        extractYear(date(order(d))) = y MATERIALIZED;
rating 'Рейтинг' (Customer c, Product p, INTEGER y) = 
    PARTITION SUM 1 ORDER DESC bought(c, p, y), p BY c, y MATERIALIZED;
SELECT contactName(Customer c), name(Product p) WHERE rating(c, p, 1997) < 3;


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

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

parent = DATA Group (Group);


एक कार्यात्मक डेटाबेस में, रिकर्सन तर्क को निम्नानुसार निर्दिष्ट किया जा सकता है:

level (Group child, Group parent) = RECURSION 1l IF child IS Group AND parent == child
                                                             STEP 2l IF parent == parent($parent);
isParent (Group child, Group parent) = TRUE IF level(child, parent) MATERIALIZED;


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

childrenCount (Group g) = GROUP SUM 1 IF isParent(Group child, g);


SQL क्वेरी में कोई CTE नहीं होगा. इसके बजाय एक साधारण ग्रुप बाय होगा।

इस तंत्र का उपयोग करके, यदि आवश्यक हो तो आप डेटाबेस को आसानी से असामान्य भी कर सकते हैं:

CLASS Order 'Заказ';
date 'Дата' = DATA DATE (Order);

CLASS OrderDetail 'Строка заказа';
order 'Заказ' = DATA Order (OrderDetail);
date 'Дата' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;


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

लाभ

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

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

एनालॉग

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

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

दूसरे, उन पर बड़ी संख्या में प्रतिबंध हैं:

ओरेकल

5.3.8.4 फास्ट रिफ्रेश पर सामान्य प्रतिबंध

भौतिक दृश्य की परिभाषित क्वेरी निम्नानुसार प्रतिबंधित है:

• भौतिक दृश्य में गैर-दोहराई जाने वाली अभिव्यक्तियों का संदर्भ नहीं होना चाहिए जैसे SYSDATE और ROWNUM.
• भौतिक दृश्य में संदर्भ नहीं होना चाहिए RAW or LONG RAW जानकारी का प्रकार।
• इसमें a शामिल नहीं हो सकता SELECT सूची सबक्वेरी.
• इसमें विश्लेषणात्मक कार्य नहीं हो सकते (उदाहरण के लिए, RANKमें) SELECT खंड।
• यह उस तालिका का संदर्भ नहीं दे सकता जिस पर a XMLIndex सूचकांक परिभाषित किया गया है।
• इसमें a शामिल नहीं हो सकता MODEL खंड।
• इसमें a शामिल नहीं हो सकता HAVING एक उप क्वेरी के साथ खंड.
• इसमें नेस्टेड क्वेरीज़ शामिल नहीं हो सकतीं ANY, ALLया, NOT EXISTS.
• इसमें a शामिल नहीं हो सकता [START WITH …] CONNECT BY खंड।
• इसमें विभिन्न साइटों पर एकाधिक विवरण तालिकाएँ नहीं हो सकतीं।
• ON COMMIT भौतिक दृश्यों में दूरस्थ विवरण तालिकाएँ नहीं हो सकतीं।
• नेस्टेड भौतिक विचारों में एक जुड़ाव या समुच्चय होना चाहिए।
• विचारों को मूर्त रूप दिया गया और विचारों को एक के साथ मूर्त रूप दिया गया GROUP BY खंड सूचकांक-संगठित तालिका से चयन नहीं कर सकता।

5.3.8.5 केवल जॉइन के साथ भौतिक दृश्यों पर फास्ट रिफ्रेश पर प्रतिबंध

केवल जॉइन और बिना किसी एग्रीगेट वाले भौतिक दृश्यों के लिए प्रश्नों को परिभाषित करने पर तेजी से ताज़ा करने पर निम्नलिखित प्रतिबंध हैं:

• से सभी प्रतिबंधफास्ट रिफ्रेश पर सामान्य प्रतिबंध"।
• उनके पास नहीं हो सकता GROUP BY खंड या समुच्चय.
• सभी तालिकाओं की पंक्तियाँ FROM सूची में प्रदर्शित होना चाहिए SELECT क्वेरी की सूची.
• सभी आधार तालिकाओं के लिए रोविड्स के साथ भौतिकीकृत दृश्य लॉग मौजूद होने चाहिए FROM क्वेरी की सूची.
• आप सरल जोड़ वाली कई तालिकाओं से एक तेज़ ताज़ा करने योग्य भौतिक दृश्य नहीं बना सकते हैं जिसमें एक ऑब्जेक्ट प्रकार कॉलम शामिल है SELECT बयान।

साथ ही, आपके द्वारा चुनी गई ताज़ा विधि इष्टतम रूप से कुशल नहीं होगी यदि:

• परिभाषित क्वेरी एक बाहरी जुड़ाव का उपयोग करती है जो आंतरिक जुड़ाव की तरह व्यवहार करती है। यदि परिभाषित क्वेरी में ऐसा जुड़ाव शामिल है, तो आंतरिक जुड़ाव शामिल करने के लिए परिभाषित क्वेरी को फिर से लिखने पर विचार करें।
• RSI SELECT भौतिक दृश्य की सूची में एकाधिक तालिकाओं के स्तंभों पर अभिव्यक्तियाँ शामिल हैं।

5.3.8.6 समुच्चय के साथ भौतिक दृश्यों पर फास्ट रिफ्रेश पर प्रतिबंध

समुच्चय या जुड़ाव के साथ भौतिक दृश्यों के लिए क्वेरी को परिभाषित करने पर तेजी से ताज़ा करने पर निम्नलिखित प्रतिबंध हैं:

• से सभी प्रतिबंधफास्ट रिफ्रेश पर सामान्य प्रतिबंध"।

दोनों के लिए फास्ट रिफ्रेश समर्थित है ON COMMIT और ON DEMAND भौतिक विचार, हालाँकि निम्नलिखित प्रतिबंध लागू होते हैं:

• भौतिक दृश्य में सभी तालिकाओं में भौतिक दृश्य लॉग होने चाहिए, और भौतिक दृश्य लॉग में:
  • भौतिक दृश्य में संदर्भित तालिका से सभी कॉलम शामिल करें।
  • के साथ निर्दिष्ट करें ROWID और INCLUDING NEW VALUES.
  • विवरण दें SEQUENCE यदि तालिका में इन्सर्ट/डायरेक्ट-लोड, डिलीट और अपडेट का मिश्रण होने की उम्मीद है तो क्लॉज।

• केवल SUM, COUNT, AVG, STDDEV, VARIANCE, MIN और MAX तेज़ रिफ्रेश के लिए समर्थित हैं।
• COUNT(*) निर्दिष्ट किया जाना चाहिए।
• समग्र कार्य केवल अभिव्यक्ति के सबसे बाहरी भाग के रूप में होने चाहिए। यानी समुच्चय जैसे AVG(AVG(x)) or AVG(x)+ AVG(x) अनुमति नहीं है।
• जैसे प्रत्येक समुच्चय के लिए AVG(expr), अनुरूप COUNT(expr) अनिवार्य उपस्थिति। ओरेकल इसकी अनुशंसा करता है SUM(expr) निर्दिष्ट किया जाए।
• If VARIANCE(expr) or STDDEV(expr) निर्दिष्ट किया जाता है, COUNT(expr) और SUM(expr) निर्दिष्ट किया जाना चाहिए. ओरेकल इसकी अनुशंसा करता है SUM(expr *expr) निर्दिष्ट किया जाए।
• RSI SELECT परिभाषित क्वेरी में कॉलम कई आधार तालिकाओं के कॉलम के साथ एक जटिल अभिव्यक्ति नहीं हो सकता है। इसका एक संभावित समाधान नेस्टेड भौतिक दृश्य का उपयोग करना है।
• RSI SELECT सूची में सभी शामिल होने चाहिए GROUP BY कॉलम।
• भौतिक दृश्य एक या अधिक दूरस्थ तालिकाओं पर आधारित नहीं है।
• अगर आप ए CHAR भौतिकीकृत दृश्य लॉग के फ़िल्टर कॉलम में डेटा प्रकार, मास्टर साइट के वर्ण सेट और भौतिकीकृत दृश्य समान होने चाहिए।
• यदि भौतिक दृश्य में निम्नलिखित में से एक है, तो तेज़ रिफ्रेश केवल पारंपरिक डीएमएल आवेषण और प्रत्यक्ष लोड पर समर्थित है।
  • के साथ भौतिक विचार MIN or MAX समुच्चय
  • जिन विचारों को मूर्त रूप दिया गया है SUM(expr) लेकिन नहीं COUNT(expr)
  • बिना भौतिक विचार COUNT(*)

  ऐसे भौतिकीकृत दृश्य को केवल-सम्मिलित भौतिकीकृत दृश्य कहा जाता है।

• के साथ एक भौतिक दृष्टिकोण MAX or MIN यदि इसमें कोई नहीं है तो डिलीट या मिश्रित डीएमएल स्टेटमेंट के बाद तेजी से रीफ्रेश किया जा सकता है WHERE खंड।
  डिलीट या मिश्रित डीएमएल के बाद अधिकतम/मिनट तेज़ रिफ्रेश का व्यवहार इन्सर्ट-ओनली केस के समान नहीं होता है। यह प्रभावित समूहों के लिए अधिकतम/न्यूनतम मानों को हटाता है और पुनः गणना करता है। आपको इसके प्रदर्शन प्रभाव के बारे में जागरूक होना होगा।
• नामित विचारों या उपश्रेणियों के साथ भौतिकीकृत दृश्य FROM क्लॉज को तुरंत ताज़ा किया जा सकता है बशर्ते कि दृश्यों को पूरी तरह से मर्ज किया जा सके। किन विचारों का विलय होगा, इसकी जानकारी के लिए देखें Oracle डेटाबेस SQL ​​भाषा संदर्भ.
• यदि कोई बाहरी जुड़ाव नहीं है, तो आपके पास मनमाने ढंग से चयन और जोड़ हो सकते हैं WHERE खंड।
• बाहरी जुड़ाव के साथ भौतिक समग्र दृश्य पारंपरिक डीएमएल और प्रत्यक्ष लोड के बाद तेजी से ताज़ा हो जाते हैं, बशर्ते केवल बाहरी तालिका को संशोधित किया गया हो। साथ ही, इनर जॉइन टेबल के जॉइन कॉलम पर अद्वितीय बाधाएं मौजूद होनी चाहिए। यदि बाहरी जोड़ हैं, तो सभी जोड़ जुड़े होने चाहिए ANDs और समानता का उपयोग करना चाहिए (=) ऑपरेटर।
• भौतिक विचारों के लिए CUBE, ROLLUP, समूहीकरण सेट, या उनका संयोजन, निम्नलिखित प्रतिबंध लागू होते हैं:
  • RSI SELECT सूची में समूहीकरण विभेदक होना चाहिए जो या तो हो सकता है GROUPING_ID सभी पर कार्य करें GROUP BY भाव या GROUPING प्रत्येक के लिए एक कार्य करता है GROUP BY अभिव्यक्ति। उदाहरण के लिए, यदि GROUP BY भौतिक दृष्टिकोण का खंड है "GROUP BY CUBE(a, b)", फिर SELECT सूची में या तो शामिल होना चाहिए "GROUPING_ID(a, b)" या "GROUPING(a) AND GROUPING(b)» भौतिक दृश्य को तेजी से ताज़ा करने योग्य बनाने के लिए।
  • GROUP BY किसी भी डुप्लिकेट समूहीकरण का परिणाम नहीं होना चाहिए. उदाहरण के लिए, "GROUP BY a, ROLLUP(a, b)"यह तेजी से ताज़ा करने योग्य नहीं है क्योंकि इसके परिणामस्वरूप डुप्लिकेट ग्रुपिंग होती है"(a), (a, b), AND (a)"।

5.3.8.7 यूनियन ऑल के साथ भौतिक दृश्यों पर फास्ट रिफ्रेश पर प्रतिबंध

के साथ विचारों को मूर्त रूप दिया UNION ALL सेट ऑपरेटर समर्थन करता है REFRESH FAST विकल्प यदि निम्नलिखित शर्तें पूरी होती हैं:

• परिभाषित क्वेरी में यह होना चाहिए UNION ALL शीर्ष स्तर पर ऑपरेटर.

  RSI UNION ALL ऑपरेटर को एक अपवाद के साथ, सबक्वेरी के अंदर एम्बेड नहीं किया जा सकता है: द UNION ALL में एक सबक्वेरी में हो सकता है FROM खंड बशर्ते कि परिभाषित क्वेरी फॉर्म की हो SELECT * FROM (देखें या सबक्वेरी के साथ UNION ALL) निम्नलिखित उदाहरण के अनुसार:

  व्यू व्यू_विद_यूनियनऑल एएस बनाएं (ग्राहकों से सी.रोविड क्रिड, सी.कस्ट_आईडी, 2 उमरकर चुनें सी जहां सी.कस्ट_लास्ट_नाम = 'स्मिथ' यूनियन सभी चुनें सी.रोविड क्रिड, सी.कस्ट_आईडी, ग्राहकों से 3 उमरकर चुनें सी जहां सी.कस्ट_लास्ट_नाम = 'जोन्स'); भौतिकीकृत दृश्य बनाएं यूनियनऑल_इनसाइड_व्यू_एमवी चयन के रूप में मांग पर तेजी से ताज़ा करें * view_with_unionall से;
  

  ध्यान दें कि दृश्य view_with_unionall तेजी से ताज़ा करने की आवश्यकताओं को पूरा करता है।

• प्रत्येक क्वेरी ब्लॉक में UNION ALL क्वेरी को समुच्चय के साथ तेज़ रीफ़्रेश करने योग्य भौतिक दृश्य या जोड़ के साथ तेज़ रीफ़्रेश करने योग्य भौतिक दृश्य की आवश्यकताओं को पूरा करना चाहिए।

  संबंधित प्रकार के तेज़ ताज़ा करने योग्य भौतिकीकृत दृश्य के लिए आवश्यकतानुसार तालिकाओं पर उपयुक्त भौतिकीकृत दृश्य लॉग बनाए जाने चाहिए।
  ध्यान दें कि ओरेकल डाटाबेस एकल तालिका भौतिक दृश्य के विशेष मामले को केवल जुड़ने के साथ ही अनुमति देता है ROWID कॉलम में शामिल किया गया है SELECT सूची और भौतिक दृश्य लॉग में। यह दृश्य की परिभाषित क्वेरी में दिखाया गया है view_with_unionall.

• RSI SELECT प्रत्येक क्वेरी की सूची में एक शामिल होना चाहिए UNION ALL मार्कर, और UNION ALL प्रत्येक कॉलम में एक अलग स्थिर संख्यात्मक या स्ट्रिंग मान होना चाहिए UNION ALL शाखा। इसके अलावा, मार्कर कॉलम को उसी क्रमिक स्थिति में दिखना चाहिए SELECT प्रत्येक क्वेरी ब्लॉक की सूची। देखना "यूनियन सभी मार्कर और क्वेरी पुनर्लेखन»के संबंध में अधिक जानकारी के लिए UNION ALL चिह्नक।
• कुछ सुविधाएँ जैसे बाहरी जुड़ाव, केवल-सम्मिलित समग्र भौतिक दृश्य क्वेरी और दूरस्थ तालिकाएँ भौतिक दृश्यों के लिए समर्थित नहीं हैं UNION ALL. हालाँकि, ध्यान दें कि प्रतिकृति में उपयोग किए गए भौतिक दृश्य, जिनमें जोड़ या समुच्चय शामिल नहीं हैं, को तेजी से ताज़ा किया जा सकता है जब UNION ALL या दूरस्थ तालिकाओं का उपयोग किया जाता है।
• तेजी से ताज़ा करने योग्य भौतिक दृश्य बनाने के लिए अनुकूलता आरंभीकरण पैरामीटर को 9.2.0 या उच्चतर पर सेट किया जाना चाहिए UNION ALL.

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

Microsoft SQL सर्वर

अतिरिक्त आवश्यकताएं

SET विकल्पों और नियतात्मक फ़ंक्शन आवश्यकताओं के अलावा, निम्नलिखित आवश्यकताओं को पूरा किया जाना चाहिए:

• वह उपयोगकर्ता जो निष्पादित करता है CREATE INDEX दृश्य का स्वामी होना चाहिए.
• जब आप इंडेक्स बनाते हैं, तो IGNORE_DUP_KEY विकल्प को बंद (डिफ़ॉल्ट सेटिंग) पर सेट किया जाना चाहिए।
• तालिकाओं को दो-भाग वाले नामों से संदर्भित किया जाना चाहिए, योजना.तालिका नाम दृश्य परिभाषा में.
• दृश्य में संदर्भित उपयोगकर्ता-परिभाषित फ़ंक्शन का उपयोग करके बनाया जाना चाहिए WITH SCHEMABINDING विकल्प.
• दृश्य में संदर्भित किसी भी उपयोगकर्ता-परिभाषित फ़ंक्शन को दो-भाग वाले नामों से संदर्भित किया जाना चाहिए, ..
• उपयोगकर्ता द्वारा परिभाषित फ़ंक्शन की डेटा एक्सेस प्रॉपर्टी होनी चाहिए NO SQL, और बाहरी पहुंच संपत्ति होनी चाहिए NO.
• सामान्य भाषा रनटाइम (सीएलआर) फ़ंक्शन दृश्य की चयन सूची में दिखाई दे सकते हैं, लेकिन क्लस्टर्ड इंडेक्स कुंजी की परिभाषा का हिस्सा नहीं हो सकते। सीएलआर फ़ंक्शन दृश्य के WHERE क्लॉज या दृश्य में JOIN ऑपरेशन के ON क्लॉज में दिखाई नहीं दे सकते।
• दृश्य परिभाषा में उपयोग किए गए सीएलआर फ़ंक्शन और सीएलआर उपयोगकर्ता-परिभाषित प्रकारों के तरीकों में निम्न तालिका में दिखाए गए गुण सेट होने चाहिए।

  संपत्ति
  नोट

  नियतिवादी = सत्य
  Microsoft .NET Framework विधि की एक विशेषता के रूप में स्पष्ट रूप से घोषित किया जाना चाहिए।

  सटीक = सत्य
  .NET Framework विधि की एक विशेषता के रूप में स्पष्ट रूप से घोषित किया जाना चाहिए।

  डेटा एक्सेस = कोई एसक्यूएल नहीं
  DataAccess विशेषता को DataAccessKind.None पर और SystemDataAccess विशेषता को SystemDataAccessKind.None पर सेट करके निर्धारित किया जाता है।

  बाहरी पहुंच = नहीं
  यह प्रॉपर्टी सीएलआर रूटीन के लिए डिफ़ॉल्ट रूप से NO है।

• का उपयोग करके दृश्य बनाया जाना चाहिए WITH SCHEMABINDING विकल्प.
• दृश्य को केवल उन आधार तालिकाओं का संदर्भ देना चाहिए जो दृश्य के समान डेटाबेस में हैं। दृश्य अन्य विचारों का संदर्भ नहीं दे सकता.
• दृश्य परिभाषा में SELECT कथन में निम्नलिखित Transact-SQL तत्व शामिल नहीं होने चाहिए:

  COUNT
  रोसेट फ़ंक्शन (OPENDATASOURCE, OPENQUERY, OPENROWSET, तथा OPENXML)
  OUTER जुड़ता है (LEFT, RIGHTया, FULL)

  व्युत्पन्न तालिका (ए निर्दिष्ट करके परिभाषित)। SELECT में बयान FROM उपवाक्य)
  स्व मिलती है
  का उपयोग करके कॉलम निर्दिष्ट करना SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARPया, AVG
  सामान्य तालिका अभिव्यक्ति (सीटीई)

  नाव1, टेक्स्ट, ntext, की छवि, एक्सएमएलया, फ़ाइल धारा कॉलम
  सबक्वेरी
  OVER खंड, जिसमें रैंकिंग या समग्र विंडो फ़ंक्शन शामिल हैं

  पूर्ण-पाठ विधेय (CONTAINS, FREETEXT)
  SUM फ़ंक्शन जो एक अशक्त अभिव्यक्ति का संदर्भ देता है
  ORDER BY

  सीएलआर उपयोगकर्ता-परिभाषित समग्र फ़ंक्शन
  TOP
CUBE, ROLLUPया, GROUPING SETS ऑपरेटरों

  MIN, MAX
UNION, EXCEPTया, INTERSECT ऑपरेटरों
  TABLESAMPLE

  तालिका चर
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  विरल स्तंभ सेट
  इनलाइन (टीवीएफ) या मल्टी-स्टेटमेंट टेबल-वैल्यू फ़ंक्शंस (एमएसटीवीएफ)
  OFFSET

  CHECKSUM_AGG

  1 अनुक्रमित दृश्य में शामिल हो सकता है नाव स्तंभ; हालाँकि, ऐसे कॉलमों को क्लस्टर्ड इंडेक्स कुंजी में शामिल नहीं किया जा सकता है।

• If GROUP BY मौजूद है, दृश्य परिभाषा में शामिल होना चाहिए COUNT_BIG(*) और शामिल नहीं होना चाहिए HAVING. इन GROUP BY प्रतिबंध केवल अनुक्रमित दृश्य परिभाषा पर लागू होते हैं। एक क्वेरी अपनी निष्पादन योजना में अनुक्रमित दृश्य का उपयोग कर सकती है, भले ही वह इन्हें संतुष्ट न करे GROUP BY प्रतिबंध।
• यदि दृश्य परिभाषा में a शामिल है GROUP BY क्लॉज, अद्वितीय क्लस्टर्ड इंडेक्स की कुंजी केवल निर्दिष्ट कॉलम को संदर्भित कर सकती है GROUP BY खंड।

यहां यह स्पष्ट है कि भारतीय इसमें शामिल नहीं थे, क्योंकि उन्होंने इसे "हम थोड़ा करेंगे, लेकिन अच्छा करेंगे" योजना के अनुसार करने का फैसला किया। यानी उनके पास मैदान पर अधिक खदानें हैं, लेकिन उनका स्थान अधिक पारदर्शी है। सबसे निराशाजनक बात यह सीमा है:

दृश्य को केवल उन आधार तालिकाओं का संदर्भ देना चाहिए जो दृश्य के समान डेटाबेस में हैं। दृश्य अन्य विचारों का संदर्भ नहीं दे सकता.

हमारी शब्दावली में, इसका मतलब यह है कि एक फ़ंक्शन किसी अन्य भौतिक फ़ंक्शन तक नहीं पहुंच सकता है। यह शुरुआत में ही सभी विचारधाराओं को ख़त्म कर देता है।
साथ ही, यह सीमा (और पाठ में आगे) उपयोग के मामलों को बहुत कम कर देती है:

दृश्य परिभाषा में SELECT कथन में निम्नलिखित Transact-SQL तत्व शामिल नहीं होने चाहिए:

COUNT
रोसेट फ़ंक्शन (OPENDATASOURCE, OPENQUERY, OPENROWSET, तथा OPENXML)
OUTER जुड़ता है (LEFT, RIGHTया, FULL)

व्युत्पन्न तालिका (ए निर्दिष्ट करके परिभाषित)। SELECT में बयान FROM उपवाक्य)
स्व मिलती है
का उपयोग करके कॉलम निर्दिष्ट करना SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARPया, AVG
सामान्य तालिका अभिव्यक्ति (सीटीई)

नाव1, टेक्स्ट, ntext, की छवि, एक्सएमएलया, फ़ाइल धारा कॉलम
सबक्वेरी
OVER खंड, जिसमें रैंकिंग या समग्र विंडो फ़ंक्शन शामिल हैं

पूर्ण-पाठ विधेय (CONTAINS, FREETEXT)
SUM फ़ंक्शन जो एक अशक्त अभिव्यक्ति का संदर्भ देता है
ORDER BY

सीएलआर उपयोगकर्ता-परिभाषित समग्र फ़ंक्शन
TOP
CUBE, ROLLUPया, GROUPING SETS ऑपरेटरों

MIN, MAX
UNION, EXCEPTया, INTERSECT ऑपरेटरों
TABLESAMPLE

तालिका चर
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

विरल स्तंभ सेट
इनलाइन (टीवीएफ) या मल्टी-स्टेटमेंट टेबल-वैल्यू फ़ंक्शंस (एमएसटीवीएफ)
OFFSET

CHECKSUM_AGG

बाहरी जोड़, यूनियन, ऑर्डर बाय और अन्य निषिद्ध हैं। क्या उपयोग नहीं किया जा सकता इसके बजाय यह निर्दिष्ट करना आसान हो सकता है कि क्या उपयोग किया जा सकता है। सूची संभवतः बहुत छोटी होगी.

संक्षेप में कहें तो: एलजीपीएल प्रौद्योगिकी में प्रत्येक (आइए वाणिज्यिक ध्यान दें) डीबीएमएस में प्रतिबंधों का एक बड़ा सेट बनाम कोई नहीं (एक तार्किक को छोड़कर, तकनीकी नहीं)। हालाँकि, यह ध्यान दिया जाना चाहिए कि इस तंत्र को संबंधपरक तर्क में लागू करना वर्णित कार्यात्मक तर्क की तुलना में कुछ अधिक कठिन है।

कार्यान्वयन

यह काम किस प्रकार करता है? PostgreSQL का उपयोग "वर्चुअल मशीन" के रूप में किया जाता है। इसके अंदर एक जटिल एल्गोरिदम है जो प्रश्न बनाता है। यहाँ स्रोत कोड. और ढेर सारे इफ्स के साथ अनुमानों का एक बड़ा सेट ही नहीं है। इसलिए, यदि आपके पास अध्ययन के लिए कुछ महीने हैं, तो आप वास्तुकला को समझने का प्रयास कर सकते हैं।

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

निम्नलिखित लेखों में, मैं इस बारे में भी बात करूंगा कि आप कार्यों पर प्रतिबंध कैसे लगा सकते हैं, परिवर्तन सत्रों के साथ काम कर सकते हैं और भी बहुत कुछ।

स्रोत: www.habr.com