बॅलन्सिंग डेटाबेसमध्ये लिहिते आणि वाचते

मागील मध्ये लेख मी रिलेशनल डेटाबेसप्रमाणे टेबल्स आणि फील्ड्स ऐवजी फंक्शन्सच्या आधारे तयार केलेल्या डेटाबेसची संकल्पना आणि अंमलबजावणीचे वर्णन केले आहे. याने शास्त्रीय पद्धतीपेक्षा या दृष्टिकोनाचे फायदे दर्शविणारी अनेक उदाहरणे दिली आहेत. अनेकांना ते पुरेसे पटले नाहीत.

या लेखात, मी हे दर्शवितो की ही संकल्पना तुम्हाला ऑपरेटिंग लॉजिकमध्ये कोणताही बदल न करता डेटाबेसमध्ये लेखन आणि वाचन त्वरीत आणि सोयीस्करपणे संतुलित करण्यास कशी अनुमती देते. आधुनिक व्यावसायिक डीबीएमएस (विशेषतः ओरॅकल आणि मायक्रोसॉफ्ट एसक्यूएल सर्व्हर) मध्ये अशीच कार्यक्षमता लागू करण्याचा प्रयत्न केला गेला आहे. लेखाच्या शेवटी मी हे दर्शवितो की त्यांनी जे काही केले ते सौम्यपणे सांगायचे तर ते फारसे चांगले झाले नाही.

वर्णन

पूर्वीप्रमाणे, अधिक चांगल्या प्रकारे समजून घेण्यासाठी मी उदाहरणांसह वर्णन सुरू करेन. समजा आम्हाला तर्क लागू करणे आवश्यक आहे जे विभागांची यादी त्यांच्यातील कर्मचार्‍यांची संख्या आणि त्यांचे एकूण पगार देईल.

फंक्शनल डेटाबेसमध्ये हे असे दिसेल:

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 मध्ये ही क्वेरी कार्यान्वित करण्याची जटिलता समतुल्य असेल O (कर्मचाऱ्यांची संख्या)कारण या गणनेसाठी कर्मचार्‍यांचे संपूर्ण टेबल स्कॅन करणे आणि नंतर विभागानुसार त्यांचे गट करणे आवश्यक आहे. निवडलेल्या योजनेवर अवलंबून काही लहान (विभागापेक्षा बरेच कर्मचारी आहेत असे आम्हाला वाटते) पूरक देखील असतील. ओ (कर्मचार्‍यांची लॉग संख्या) किंवा ओ (विभागांची संख्या) ग्रुपिंग वगैरेसाठी.

हे स्पष्ट आहे की वेगवेगळ्या डीबीएमएसमध्ये अंमलबजावणी ओव्हरहेड भिन्न असू शकते, परंतु जटिलता कोणत्याही प्रकारे बदलणार नाही.

प्रस्तावित अंमलबजावणीमध्ये, कार्यात्मक 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 च्या अनंत मूल्यांसाठी परिभाषित केले आहे (उदाहरणार्थ, कोणतेही नकारात्मक मूल्य योग्य आहे). त्यामुळे तुम्ही त्यावर मटेरिअलाइज्ड टाकू शकत नाही. तर ही तार्किक मर्यादा आहे, तांत्रिक नाही (म्हणजे आम्ही ती अंमलात आणू शकलो नाही म्हणून नाही). अन्यथा, कोणतेही निर्बंध नाहीत. तुम्ही ग्रुपिंग, सॉर्टिंग, AND आणि OR, PARTITION, recursion इत्यादी वापरू शकता.

उदाहरणार्थ, मागील लेखाच्या समस्या 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;


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

या यंत्रणेचा वापर करून, तुम्ही, उदाहरणार्थ, प्रश्नांमधील पुनरावृत्ती (CTE) पासून मुक्त होऊ शकता. विशेषतः, मूल/पालक नातेसंबंध वापरून वृक्ष तयार करणार्‍या गटांचा विचार करा (प्रत्येक गटाला त्याच्या पालकांची लिंक असते):

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 नसेल. त्याऐवजी एक साधा GROUP BY असेल.

या यंत्रणेचा वापर करून, आवश्यक असल्यास, आपण डेटाबेस सहजपणे विकृत करू शकता:

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

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


फंक्शन कॉल करताना तारीख ऑर्डर लाइनसाठी, ज्या फील्डसाठी इंडेक्स आहे ते टेबलमधून ऑर्डर लाईन्ससह वाचले जाईल. जेव्हा ऑर्डरची तारीख बदलते, तेव्हा सिस्टम स्वतःच ओळीतील डिनोर्मलाइज्ड तारखेची पुनर्गणना करेल.

फायदे

ही संपूर्ण यंत्रणा कशासाठी आहे? क्लासिक DBMS मध्ये, पुनर्लेखन क्वेरीशिवाय, विकासक किंवा DBA फक्त अनुक्रमणिका बदलू शकतात, आकडेवारी निर्धारित करू शकतात आणि क्वेरी प्लॅनरला ते कसे कार्यान्वित करायचे ते सांगू शकतात (आणि HINTs फक्त व्यावसायिक DBMS मध्ये उपलब्ध आहेत). त्यांनी कितीही प्रयत्न केले तरी ते मधील लेखातील पहिली क्वेरी पूर्ण करू शकणार नाहीत ओ (विभागांची संख्या) क्वेरी न बदलता किंवा ट्रिगर जोडल्याशिवाय. प्रस्तावित योजनेत, विकासाच्या टप्प्यावर तुम्हाला डेटा स्टोरेज स्ट्रक्चर आणि कोणते एकत्रीकरण वापरायचे याचा विचार करण्याची गरज नाही. हे सर्व फ्लायवर, थेट ऑपरेशनमध्ये सहजपणे बदलले जाऊ शकते.

सराव मध्ये हे असे दिसते. काही लोक थेट हातात असलेल्या कामावर आधारित तर्कशास्त्र विकसित करतात. त्यांना अल्गोरिदम आणि त्यांची जटिलता, अंमलबजावणी योजना, जोडण्याचे प्रकार किंवा इतर कोणतेही तांत्रिक घटक समजत नाहीत. हे लोक विकासकांपेक्षा अधिक व्यवसाय विश्लेषक आहेत. मग, हे सर्व चाचणी किंवा ऑपरेशनमध्ये जाते. दीर्घकाळ चालणाऱ्या क्वेरीचे लॉगिंग सक्षम करते. जेव्हा एखादी दीर्घ क्वेरी आढळली, तेव्हा इतर लोक (अधिक तांत्रिक - मूलत: DBA) काही इंटरमीडिएट फंक्शनवर MATERIALIZED सक्षम करण्याचा निर्णय घेतात. हे रेकॉर्डिंग थोडे कमी करते (कारण त्याला व्यवहारात अतिरिक्त फील्ड अद्यतनित करणे आवश्यक आहे). तथापि, केवळ या क्वेरीला लक्षणीयरीत्या गती दिली जात नाही तर हे कार्य वापरणारे इतर सर्व देखील. त्याच वेळी, कोणते कार्य प्रत्यक्षात आणायचे हे ठरवणे तुलनेने सोपे आहे. दोन मुख्य पॅरामीटर्स: संभाव्य इनपुट मूल्यांची संख्या (संबंधित सारणीमध्ये किती रेकॉर्ड असतील) आणि इतर फंक्शन्समध्ये ते किती वेळा वापरले जाते.

अॅनालॉग

आधुनिक व्यावसायिक डीबीएमएसमध्ये समान यंत्रणा आहेत: जलद रिफ्रेश (ओरेकल) आणि अनुक्रमित दृश्य (मायक्रोसॉफ्ट एसक्यूएल सर्व्हर) सह मटेरियलाइज्ड व्ह्यू. PostgreSQL मध्‍ये, मटेरिअलाइज्ड दृश्‍य व्‍यवहारात अपडेट करता येत नाही, परंतु केवळ विनंतीनुसार (आणि अगदी कडक निर्बंध असले तरीही), त्यामुळे आम्ही त्याचा विचार करत नाही. परंतु त्यांच्याकडे बर्‍याच समस्या आहेत ज्या त्यांचा वापर लक्षणीयरीत्या मर्यादित करतात.

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

दुसरे म्हणजे, त्यांच्याकडे मोठ्या संख्येने निर्बंध आहेत:

ओरॅकल

5.3.8.4 जलद रीफ्रेश वर सामान्य निर्बंध

भौतिकीकृत दृश्याची परिभाषित क्वेरी खालीलप्रमाणे प्रतिबंधित आहे:

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

5.3.8.5 केवळ सामील असलेल्या मटेरिअलाइज्ड व्ह्यूजवर फास्ट रिफ्रेशवर निर्बंध

केवळ जॉइन्ससह भौतिक दृश्यांसाठी क्वेरी परिभाषित करणे आणि कोणत्याही समुच्चयांमध्ये जलद रीफ्रेशवर खालील निर्बंध नाहीत:

• पासून सर्व निर्बंध «जलद रीफ्रेश वर सामान्य निर्बंध".
• त्यांच्याकडे असू शकत नाही GROUP BY खंड किंवा एकत्रित.
• मधील सर्व टेबल्सच्या रोविड्स FROM मध्ये यादी दिसणे आवश्यक आहे SELECT क्वेरीची यादी.
• मटेरियलाइज्ड व्ह्यू लॉग मधील सर्व बेस टेबल्ससाठी रोविड्ससह अस्तित्वात असणे आवश्यक आहे FROM क्वेरीची यादी.
• तुम्ही एकापेक्षा जास्त सारण्यांमधून एक जलद रीफ्रेश करण्यायोग्य मटेरियलाइज्ड व्ह्यू तयार करू शकत नाही ज्यात साध्या जोडणीमध्ये ऑब्जेक्ट प्रकार स्तंभ समाविष्ट आहे. SELECT विधान

तसेच, तुम्ही निवडलेली रीफ्रेश पद्धत चांगल्या प्रकारे कार्यक्षम होणार नाही जर:

• परिभाषित क्वेरी बाह्य जोड वापरते जे अंतर्गत जोडण्यासारखे वागते. परिभाषित क्वेरीमध्ये असे जोड असल्यास, अंतर्गत जोड समाविष्ट करण्यासाठी परिभाषित क्वेरी पुन्हा लिहिण्याचा विचार करा.
• अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना 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) निर्दिष्ट करणे.
• अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना SELECT परिभाषित क्वेरीमधील स्तंभ अनेक बेस टेबलमधील स्तंभांसह जटिल अभिव्यक्ती असू शकत नाही. यासाठी संभाव्य उपाय म्हणजे नेस्टेड मटेरियलाइज्ड व्ह्यू वापरणे.
• अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना SELECT सूचीमध्ये सर्व असणे आवश्यक आहे GROUP BY स्तंभ.
• भौतिकीकृत दृश्य एक किंवा अधिक दूरस्थ सारण्यांवर आधारित नाही.
• आपण वापरल्यास CHAR मटेरियलाइज्ड व्ह्यू लॉगच्या फिल्टर कॉलम्समधील डेटा प्रकार, मास्टर साइटचे कॅरेक्टर सेट्स आणि मटेरियलाइज्ड व्ह्यू सारखेच असणे आवश्यक आहे.
• जर मटेरियलाइज्ड व्ह्यूमध्ये खालीलपैकी एक असेल, तर फास्ट रिफ्रेशला फक्त पारंपारिक डीएमएल इन्सर्ट आणि डायरेक्ट लोडवर सपोर्ट केले जाते.
  • सह भौतिक दृश्ये MIN or MAX एकूण
  • ज्यात भौतिक दृश्ये आहेत SUM(expr) पण नाही COUNT(expr)
  • न भौतिक दृश्ये COUNT(*)

  अशा मटेरियलाइज्ड व्ह्यूला इन्सर्ट-ओन्ली मटेरियलाइज्ड व्ह्यू म्हणतात.

• सह एक भौतिक दृश्य MAX or MIN डिलीट किंवा मिश्रित डीएमएल स्टेटमेंट नंतर त्वरीत रिफ्रेश करण्यायोग्य आहे जर त्यात ए नसेल WHERE खंड
  डिलीट किंवा मिश्रित DML नंतर कमाल/मिनिट जलद रिफ्रेशमध्ये फक्त-इन्सर्ट केस सारखे वर्तन नसते. हे प्रभावित गटांसाठी कमाल/मिनिट मूल्ये हटवते आणि पुन्हा मोजते. आपल्याला त्याच्या कार्यक्षमतेच्या प्रभावाची जाणीव असणे आवश्यक आहे.
• मध्ये नामांकित दृश्ये किंवा सबक्वेरीसह भौतिक दृश्ये FROM खंड त्वरीत रीफ्रेश केला जाऊ शकतो जर दृश्ये पूर्णपणे विलीन केली जाऊ शकतात. कोणती दृश्ये विलीन होतील या माहितीसाठी, पहा ओरॅकल डेटाबेस SQL ​​भाषा संदर्भ.
• कोणतेही बाह्य सामील नसल्यास, तुमच्याकडे अनियंत्रित निवडी असू शकतात आणि मध्ये सामील होऊ शकतात WHERE खंड
• बाह्य जोड्यांसह भौतिक एकत्रित दृश्ये पारंपारिक डीएमएल आणि थेट भारानंतर जलद रीफ्रेश करण्यायोग्य असतात, बशर्ते केवळ बाह्य सारणी सुधारित केली गेली असेल. तसेच, आतील जॉईन टेबलच्या जॉईन कॉलमवर अनन्य मर्यादा असणे आवश्यक आहे. जर बाहेरील जोड असतील तर, सर्व जोड द्वारे जोडलेले असणे आवश्यक आहे ANDs आणि समानता वापरणे आवश्यक आहे (=) ऑपरेटर.
• सह भौतिक दृश्यांसाठी CUBE, ROLLUP, गटबद्ध संच किंवा त्यांचे एकत्रीकरण, खालील निर्बंध लागू होतात:
  • अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना 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 सह मटेरियलाइज्ड व्ह्यूजवर फास्ट रिफ्रेशवर निर्बंध

सह भौतिक दृश्ये UNION ALL सेट ऑपरेटर समर्थन REFRESH FAST खालील अटी पूर्ण झाल्यास पर्याय:

• परिभाषित क्वेरीमध्ये असणे आवश्यक आहे UNION ALL शीर्ष स्तरावर ऑपरेटर.

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

  View_with_unionall AS दृश्य तयार करा (ग्राहकांकडून c.rowid crid, c.cust_id, 2 umarker निवडा c WHERE c.cust_last_name = 'Smith' UNION सर्व निवडा c.rowid crid, c.cust_id, 3 umarker ग्राहकांकडून c_last_name = WHERE c_last. 'जोन्स'); युनिअल_इनसाइड_व्यू_एमव्ही मटेरिअलाइज्ड व्ह्यू तयार करा * सिलेक्ट म्हणून मागणीनुसार जलद रिफ्रेश करा.
  

  लक्षात घ्या की दृश्य view_with_unionall जलद रिफ्रेशसाठी आवश्यकता पूर्ण करते.

• मध्ये प्रत्येक क्वेरी ब्लॉक UNION ALL क्वेरीने समुच्चयांसह जलद रीफ्रेश करण्यायोग्य मटेरियलाइज्ड व्ह्यू किंवा जॉइन्ससह जलद रिफ्रेश करण्यायोग्य मटेरियलाइज्ड व्ह्यूची आवश्यकता पूर्ण करणे आवश्यक आहे.

  संबंधित प्रकारच्या जलद रीफ्रेश करण्यायोग्य मटेरियलाइज्ड व्ह्यूसाठी आवश्यकतेनुसार टेबलवर योग्य मटेरियलाइज्ड व्ह्यू लॉग तयार करणे आवश्यक आहे.
  लक्षात घ्या की ओरॅकल डेटाबेस केवळ जोडणीसह एकल टेबल मटेरियलाइज्ड व्ह्यूच्या विशेष केसला परवानगी देतो ROWID मध्ये स्तंभ समाविष्ट केला आहे SELECT सूची आणि भौतिक दृश्य लॉगमध्ये. हे दृश्याच्या परिभाषित क्वेरीमध्ये दर्शविले आहे view_with_unionall.

• अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना SELECT प्रत्येक क्वेरीच्या सूचीमध्ये समाविष्ट करणे आवश्यक आहे UNION ALL मार्कर, आणि द UNION ALL स्तंभामध्ये प्रत्येकामध्ये एक वेगळे स्थिर अंकीय किंवा स्ट्रिंग मूल्य असणे आवश्यक आहे UNION ALL शाखा पुढे, मार्कर स्तंभ मध्ये समान क्रमिक स्थितीत दिसणे आवश्यक आहे SELECT प्रत्येक क्वेरी ब्लॉकची यादी. पहा "युनियन सर्व मार्कर आणि क्वेरी पुनर्लेखन»संबंधित अधिक माहितीसाठी UNION ALL मार्कर
• काही वैशिष्ट्ये जसे की बाह्य जोडणे, फक्त-समाविष्ट केलेले एकत्रित दृश्य क्वेरी आणि रिमोट टेबल्स यासह भौतिक दृश्यांसाठी समर्थित नाहीत UNION ALL. लक्षात ठेवा, तथापि, प्रतिकृतीमध्ये वापरलेली भौतिक दृश्ये, ज्यात जोडणे किंवा एकत्रित नसतात, ते जलद रीफ्रेश केले जाऊ शकतात जेव्हा UNION ALL किंवा रिमोट टेबल वापरले जातात.
• यासह जलद रीफ्रेश करण्यायोग्य मटेरियलाइज्ड व्ह्यू तयार करण्यासाठी सुसंगतता आरंभिकरण पॅरामीटर 9.2.0 किंवा उच्च वर सेट करणे आवश्यक आहे. UNION ALL.

मला ओरॅकलच्या चाहत्यांना नाराज करायचे नाही, परंतु त्यांच्या निर्बंधांच्या यादीनुसार, असे दिसते की ही यंत्रणा सामान्य प्रकरणात काही प्रकारचे मॉडेल वापरून लिहिलेली नाही, तर हजारो भारतीयांनी लिहिली होती, जिथे प्रत्येकाला संधी दिली गेली होती. त्यांची स्वतःची शाखा लिहा, आणि त्यांच्यापैकी प्रत्येकाने शक्य ते केले आणि केले. वास्तविक तर्कशास्त्रासाठी ही यंत्रणा वापरणे म्हणजे माइनफील्डमधून चालण्यासारखे आहे. स्पष्ट नसलेल्या निर्बंधांपैकी एक दाबून तुम्ही कधीही खाण मिळवू शकता. ते कसे कार्य करते हा देखील एक स्वतंत्र प्रश्न आहे, परंतु तो या लेखाच्या व्याप्तीच्या बाहेर आहे.

मायक्रोसॉफ्ट एस क्यू एल सर्व्हर

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

SET पर्याय आणि निर्धारक कार्य आवश्यकतांव्यतिरिक्त, खालील आवश्यकता पूर्ण केल्या पाहिजेत:

• कार्यान्वित करणारा वापरकर्ता CREATE INDEX दृश्याचा मालक असणे आवश्यक आहे.
• आपण अनुक्रमणिका तयार करता तेव्हा, द IGNORE_DUP_KEY पर्याय बंद (डीफॉल्ट सेटिंग) वर सेट करणे आवश्यक आहे.
• सारण्या दोन-भागांच्या नावांनी संदर्भित केल्या पाहिजेत, योजना.टेबलनाव दृश्य व्याख्या मध्ये.
• दृश्यात संदर्भित वापरकर्ता-परिभाषित कार्ये वापरून तयार करणे आवश्यक आहे WITH SCHEMABINDING पर्याय.
• दृश्यात संदर्भित केलेली कोणतीही वापरकर्ता-परिभाषित कार्ये दोन-भागांच्या नावांनी संदर्भित केली पाहिजेत, ..
• वापरकर्ता-परिभाषित कार्याची डेटा ऍक्सेस गुणधर्म असणे आवश्यक आहे NO SQL, आणि बाह्य प्रवेश मालमत्ता असणे आवश्यक आहे NO.
• कॉमन लँग्वेज रनटाइम (CLR) फंक्शन्स दृश्याच्या निवडलेल्या सूचीमध्ये दिसू शकतात, परंतु क्लस्टर केलेल्या इंडेक्स कीच्या व्याख्येचा भाग असू शकत नाहीत. CLR फंक्शन्स व्ह्यूच्या WHERE क्लॉजमध्ये किंवा व्ह्यूमध्ये जॉइन ऑपरेशनच्या चालू क्लॉजमध्ये दिसू शकत नाहीत.
• सीएलआर फंक्शन्स आणि व्ह्यू डेफिनिशनमध्ये वापरल्या जाणार्‍या सीएलआर वापरकर्ता-परिभाषित प्रकारांच्या पद्धतींमध्ये खालील तक्त्यामध्ये दर्शविल्याप्रमाणे गुणधर्म सेट असणे आवश्यक आहे.

  मालमत्ता
  टीप

  निर्धारवादी = सत्य
  Microsoft .NET फ्रेमवर्क पद्धतीची विशेषता म्हणून स्पष्टपणे घोषित करणे आवश्यक आहे.

  अचूक = खरे
  .NET फ्रेमवर्क पद्धतीची विशेषता म्हणून स्पष्टपणे घोषित करणे आवश्यक आहे.

  डेटा ऍक्सेस = एसक्यूएल नाही
  DataAccessKind.None वर DataAccess विशेषता सेट करून आणि SystemDataAccessKind.None वर SystemDataAccess विशेषता सेट करून निर्धारित केले जाते.

  बाह्य प्रवेश = नाही
  ही मालमत्ता CLR रूटीनसाठी NO वर डीफॉल्ट आहे.

• वापरून दृश्य तयार करणे आवश्यक आहे WITH SCHEMABINDING पर्याय.
• व्ह्यूमध्ये फक्त बेस टेबल्सचा संदर्भ असणे आवश्यक आहे जे व्ह्यू सारख्या डेटाबेसमध्ये आहेत. दृश्य इतर दृश्यांचा संदर्भ देऊ शकत नाही.
• व्ह्यू डेफिनिशनमधील SELECT स्टेटमेंटमध्ये खालील Transact-SQL घटक नसावेत:

  COUNT
  ROWSET फंक्शन्स (OPENDATASOURCE, OPENQUERY, OPENROWSET, आणि OPENXML)
  OUTER सामील होतो(LEFT, RIGHTकिंवा FULL)

  व्युत्पन्न सारणी (निर्दिष्ट करून परिभाषित SELECT मध्ये विधान FROM खंड)
  स्वत: सामील होतात
  वापरून स्तंभ निर्दिष्ट करणे SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARPकिंवा AVG
  कॉमन टेबल एक्सप्रेशन (CTE)

  फ्लोट1, मजकूर, ntext, प्रतिमा, एक्स एम एलकिंवा फाइलस्ट्रीम स्तंभ
  सबक्वेरी
  OVER खंड, ज्यामध्ये रँकिंग किंवा एकूण विंडो कार्ये समाविष्ट आहेत

  पूर्ण मजकूर अंदाज (CONTAINS, FREETEXT)
  SUM फंक्शन जे एक रद्द करण्यायोग्य अभिव्यक्तीचा संदर्भ देते
  ORDER BY

  CLR वापरकर्ता-परिभाषित एकूण कार्य
  TOP
CUBE, ROLLUPकिंवा GROUPING SETS ऑपरेटर

  MIN, MAX
UNION, EXCEPTकिंवा INTERSECT ऑपरेटर
  TABLESAMPLE

  टेबल व्हेरिएबल्स
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  विरळ स्तंभ संच
  इनलाइन (TVF) किंवा मल्टी-स्टेटमेंट टेबल-व्हॅल्यूड फंक्शन्स (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 अनुक्रमित दृश्यामध्ये असू शकते फ्लोट स्तंभ; तथापि, असे स्तंभ क्लस्टर केलेल्या इंडेक्स कीमध्ये समाविष्ट केले जाऊ शकत नाहीत.

• If GROUP BY उपस्थित आहे, VIEW व्याख्येमध्ये असणे आवश्यक आहे COUNT_BIG(*) आणि समाविष्ट नसावे HAVING. या GROUP BY निर्बंध केवळ अनुक्रमित दृश्य व्याख्येवर लागू आहेत. एक क्वेरी त्याच्या अंमलबजावणी योजनेत अनुक्रमित दृश्य वापरू शकते जरी ती या गोष्टींचे समाधान करत नसली तरीही GROUP BY निर्बंध
• जर दृश्याच्या व्याख्येमध्ये अ GROUP BY खंड, अद्वितीय क्लस्टर केलेल्या निर्देशांकाची की फक्त मध्ये निर्दिष्ट केलेल्या स्तंभांचा संदर्भ देऊ शकते GROUP BY खंड

येथे हे स्पष्ट आहे की भारतीयांचा त्यात सहभाग नव्हता, कारण त्यांनी "आम्ही थोडे पण चांगले करू" या योजनेनुसार ते करण्याचे ठरविले. म्हणजेच, त्यांच्याकडे शेतात जास्त खाणी आहेत, परंतु त्यांचे स्थान अधिक पारदर्शक आहे. सर्वात निराशाजनक गोष्ट ही मर्यादा आहे:

व्ह्यूमध्ये फक्त बेस टेबल्सचा संदर्भ असणे आवश्यक आहे जे व्ह्यू सारख्या डेटाबेसमध्ये आहेत. दृश्य इतर दृश्यांचा संदर्भ देऊ शकत नाही.

आमच्या टर्मिनोलॉजीमध्ये, याचा अर्थ असा आहे की फंक्शन दुसर्या भौतिकीकृत फंक्शनमध्ये प्रवेश करू शकत नाही. यामुळे अंकुरातील सर्व विचारधारा नष्ट होतात.
तसेच, ही मर्यादा (आणि पुढे मजकूरात) वापर प्रकरणे मोठ्या प्रमाणात कमी करते:

व्ह्यू डेफिनिशनमधील SELECT स्टेटमेंटमध्ये खालील Transact-SQL घटक नसावेत:

COUNT
ROWSET फंक्शन्स (OPENDATASOURCE, OPENQUERY, OPENROWSET, आणि OPENXML)
OUTER सामील होतो(LEFT, RIGHTकिंवा FULL)

व्युत्पन्न सारणी (निर्दिष्ट करून परिभाषित SELECT मध्ये विधान FROM खंड)
स्वत: सामील होतात
वापरून स्तंभ निर्दिष्ट करणे SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARPकिंवा AVG
कॉमन टेबल एक्सप्रेशन (CTE)

फ्लोट1, मजकूर, ntext, प्रतिमा, एक्स एम एलकिंवा फाइलस्ट्रीम स्तंभ
सबक्वेरी
OVER खंड, ज्यामध्ये रँकिंग किंवा एकूण विंडो कार्ये समाविष्ट आहेत

पूर्ण मजकूर अंदाज (CONTAINS, FREETEXT)
SUM फंक्शन जे एक रद्द करण्यायोग्य अभिव्यक्तीचा संदर्भ देते
ORDER BY

CLR वापरकर्ता-परिभाषित एकूण कार्य
TOP
CUBE, ROLLUPकिंवा GROUPING SETS ऑपरेटर

MIN, MAX
UNION, EXCEPTकिंवा INTERSECT ऑपरेटर
TABLESAMPLE

टेबल व्हेरिएबल्स
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

विरळ स्तंभ संच
इनलाइन (TVF) किंवा मल्टी-स्टेटमेंट टेबल-व्हॅल्यूड फंक्शन्स (MSTVF)
OFFSET

CHECKSUM_AGG

बाह्य सामील होणे, संघ करणे, ऑर्डर करणे आणि इतरांना मनाई आहे. काय वापरले जाऊ शकत नाही यापेक्षा काय वापरले जाऊ शकते हे निर्दिष्ट करणे सोपे झाले असते. यादी कदाचित खूपच लहान असेल.

थोडक्यात: LGPL तंत्रज्ञानामध्ये प्रत्येक (व्यावसायिक लक्षात घेऊया) DBMS vs (एक तार्किक अपवाद वगळता, तांत्रिक नाही) निर्बंधांचा एक मोठा संच. तथापि, हे लक्षात घेतले पाहिजे की रिलेशनल लॉजिकमध्ये ही यंत्रणा कार्यान्वित करणे वर्णन केलेल्या कार्यात्मक तर्कापेक्षा काहीसे कठीण आहे.

अंमलबजावणी

हे कसे कार्य करते? PostgreSQL हे "व्हर्च्युअल मशीन" म्हणून वापरले जाते. आत एक जटिल अल्गोरिदम आहे जो क्वेरी तयार करतो. येथे स्त्रोत. आणि फक्त ifs च्या गुच्छासह heuristics चा एक मोठा संच नाही. म्हणून, जर तुमच्याकडे अभ्यासासाठी काही महिने असतील तर तुम्ही आर्किटेक्चर समजून घेण्याचा प्रयत्न करू शकता.

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

पुढील लेखांमध्ये, मी आपण फंक्शन्सवर निर्बंध कसे सेट करू शकता, बदल सत्रांसह कार्य करू शकता आणि बरेच काही याबद्दल देखील बोलेन.

स्त्रोत: www.habr.com