ब्यालेन्सिङले डाटाबेसमा लेख्ने र पढ्छ

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

यस लेखमा, म देखाउनेछु कि कसरी यो अवधारणाले तपाइँलाई अपरेटिङ तर्कमा कुनै परिवर्तन नगरी डाटाबेसमा लेख र पढ्नलाई छिटो र सहज रूपमा सन्तुलन गर्न अनुमति दिन्छ। समान प्रकार्यतालाई आधुनिक व्यावसायिक DBMSs (विशेष गरी, Oracle र Microsoft SQL Server) मा लागू गर्ने प्रयास गरिएको छ। लेखको अन्त्यमा म देखाउनेछु कि उनीहरूले के गरे, हल्का रूपमा भन्नुपर्दा, धेरै राम्रोसँग काम गरेन।

विवरण

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

कार्यात्मक डाटाबेसमा यो यस्तो देखिन्छ:

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 मा फरक हुन सक्छ, तर जटिलता कुनै पनि हिसाबले परिवर्तन हुनेछैन।

प्रस्तावित कार्यान्वयनमा, कार्यात्मक 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;


समारोह को लागी देखि अभिभावक हो 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;


समारोह कल गर्दा मिति अर्डर लाइनको लागि, फिल्ड जसको लागि अनुक्रमणिका छ त्यो तालिकाबाट अर्डर लाइनहरू पढिनेछ। जब अर्डर मिति परिवर्तन हुन्छ, प्रणाली आफैले स्वचालित रूपमा लाइनमा denormalized मिति पुन: गणना गर्नेछ।

लाभ

यो सम्पूर्ण संयन्त्र के का लागि हो? क्लासिक DBMSs मा, प्रश्नहरू पुन: लेख्न बिना, विकासकर्ता वा DBA ले केवल अनुक्रमणिकाहरू परिवर्तन गर्न, तथ्याङ्कहरू निर्धारण गर्न र तिनीहरूलाई कसरी कार्यान्वयन गर्ने भनेर प्रश्न योजनाकारलाई बताउन सक्छ (र HINT हरू व्यावसायिक DBMS हरूमा मात्र उपलब्ध छन्)। तिनीहरूले जतिसुकै प्रयास गरे पनि, तिनीहरूले लेखमा पहिलो प्रश्न पूरा गर्न सक्षम हुनेछैनन् ओ (विभागहरूको संख्या) प्रश्नहरू परिवर्तन नगरी वा ट्रिगरहरू थप नगरी। प्रस्तावित योजनामा, विकासको चरणमा तपाईंले डाटा भण्डारण संरचना र कुन एकत्रीकरणहरू प्रयोग गर्ने बारे सोच्नु पर्दैन। यो सबै सजिलै उडान मा, सीधा सञ्चालन मा परिवर्तन गर्न सकिन्छ।

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

Analogues

आधुनिक व्यावसायिक DBMS हरूमा समान संयन्त्रहरू छन्: फास्ट रिफ्रेश (ओरेकल) र अनुक्रमणिका दृश्य (माइक्रोसफ्ट SQL सर्भर) सँग भौतिक दृश्य। PostgreSQL मा, MATERIALIZED VIEW लेनदेनमा अद्यावधिक गर्न सकिँदैन, तर अनुरोधमा मात्र (र धेरै कडा प्रतिबन्धहरूसँग पनि), त्यसैले हामी यसलाई विचार गर्दैनौं। तर तिनीहरूसँग धेरै समस्याहरू छन् जसले उनीहरूको प्रयोगलाई महत्त्वपूर्ण रूपमा सीमित गर्दछ।

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

दोस्रो, तिनीहरूसँग ठूलो संख्यामा प्रतिबन्धहरू छन्:

बजेट

5.3.8.4 द्रुत रिफ्रेसमा सामान्य प्रतिबन्धहरू

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

• भौतिक दृश्यमा नदोहोरिने अभिव्यक्ति जस्ता सन्दर्भहरू समावेश हुनु हुँदैन SYSDATE र ROWNUM.
• भौतिक दृश्यमा सन्दर्भहरू समावेश हुनु हुँदैन RAW or LONG RAW डाटा प्रकारहरू।
• यसमा a समावेश हुन सक्दैन SELECT सूची subquery।
• यसले विश्लेषणात्मक कार्यहरू समावेश गर्न सक्दैन (उदाहरणका लागि, RANK) मा SELECT खण्ड
• यसले एउटा तालिकालाई सन्दर्भ गर्न सक्दैन जसमा ए XMLIndex सूचकांक परिभाषित छ।
• यसमा a समावेश हुन सक्दैन MODEL खण्ड
• यसमा a समावेश हुन सक्दैन HAVING subquery को साथ खण्ड।
• यसले नेस्टेड क्वेरीहरू समावेश गर्न सक्दैन ANY, ALLवा NOT EXISTS.
• यसमा a समावेश हुन सक्दैन [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) उपस्थित हुनुपर्छ। Oracle सिफारिस गर्नुभयो SUM(expr) निर्दिष्ट गर्न।
• If VARIANCE(expr) or STDDEV(expr) निर्दिष्ट गरिएको छ, COUNT(expr) र SUM(expr) निर्दिष्ट गर्नुपर्छ। Oracle सिफारिस गर्नुभयो SUM(expr *expr) निर्दिष्ट गर्न।
• यो SELECT परिभाषित क्वेरीमा स्तम्भ धेरै आधार तालिकाहरूबाट स्तम्भहरूसँग जटिल अभिव्यक्ति हुन सक्दैन। यसको सम्भावित समाधान भनेको नेस्टेड मटेरियलाइज्ड दृश्य प्रयोग गर्नु हो।
• यो SELECT सूचीमा सबै समावेश हुनुपर्छ GROUP BY स्तम्भहरू।
• भौतिक दृश्य एक वा धेरै टाढाको तालिकाहरूमा आधारित छैन।
• यदि तपाईं एक प्रयोग CHAR भौतिक दृश्य लगको फिल्टर स्तम्भहरूमा डेटा प्रकार, मास्टर साइटको क्यारेक्टर सेटहरू र भौतिक दृश्य समान हुनुपर्छ।
• यदि भौतिक दृश्यमा निम्न मध्ये एउटा छ भने, द्रुत रिफ्रेसलाई परम्परागत DML घुसाउने र प्रत्यक्ष लोडहरूमा मात्र समर्थन गरिन्छ।
  • संग भौतिक दृश्यहरु MIN or MAX समुच्चय
  • भौतिक दृश्यहरू छन् SUM(expr) तर होइन COUNT(expr)
  • बिना भौतिक दृश्यहरू COUNT(*)

  यस्तो भौतिक दृश्यलाई सम्मिलित-मात्र भौतिक दृश्य भनिन्छ।

• संग एक भौतिक दृश्य MAX or MIN मेटाउन वा मिश्रित DML कथनहरू पछि छिटो रिफ्रेस गर्न मिल्छ यदि यसमा a छैन भने WHERE खण्ड
  मेटाएपछि वा मिश्रित DML पछि अधिकतम/मिनेट द्रुत रिफ्रेस इन्सर्ट-ओन्ली केस जस्तै व्यवहार हुँदैन। यसले प्रभावित समूहहरूको लागि अधिकतम/मिनट मानहरू मेटाउँछ र पुन: गणना गर्दछ। तपाईं यसको प्रदर्शन प्रभाव बारे सचेत हुन आवश्यक छ।
• मा नामित दृश्य वा सबक्वेरीहरू सहित भौतिक दृश्यहरू FROM दृश्यहरू पूर्ण रूपमा मर्ज गर्न सकिन्छ भने खण्डलाई द्रुत रूपमा ताजा गर्न सकिन्छ। जानकारीको लागि कुन दृश्यहरू मर्ज हुनेछन्, हेर्नुहोस् ओरेकल डाटाबेस SQL ​​भाषा सन्दर्भ.
• यदि त्यहाँ कुनै बाहिरी जोडिहरू छैनन् भने, तपाईंसँग स्वेच्छाचारी छनोट हुन सक्छ र मा सामेल हुन सक्छ WHERE खण्ड
• बाहिरी जोडिहरु संग भौतिक समग्र दृश्यहरु पारंपरिक DML र प्रत्यक्ष लोड पछि छिटो रिफ्रेस योग्य छन्, केवल बाहिरी तालिका परिमार्जन गरिएको छ। साथै, भित्री जोड्ने तालिकाको जोडिने स्तम्भहरूमा अद्वितीय अवरोधहरू अवस्थित हुनुपर्छ। यदि त्यहाँ बाहिरी जोडहरू छन् भने, सबै जोडहरू जोडिएको हुनुपर्छ ANDs र समानता प्रयोग गर्नुपर्छ (=) अपरेटर।
• संग भौतिक दृश्यहरु को लागी CUBE, ROLLUP, समूहबद्ध सेटहरू, वा तिनीहरूको संयोजन, निम्न प्रतिबन्धहरू लागू हुन्छन्:
  • यो SELECT सूचीमा समूहीकरण विभेदक समावेश हुनुपर्छ जुन या त a हुन सक्छ 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 अपरेटरलाई सबक्वेरी भित्र इम्बेड गर्न सकिँदैन, एउटा अपवादको साथ: The UNION ALL मा subquery मा हुन सक्छ FROM खण्ड परिभाषित प्रश्न फारम को हो SELECT * FROM (हेर्नुहोस् वा सबक्वेरीसँग UNION ALL) निम्न उदाहरणमा जस्तै:

  दृश्य सिर्जना गर्नुहोस् 'जोन्स'); MATERIALized View unionall_inside_view_mv REFRESH FAST ON DEMAND SELECT * FROM view_with_unionall;
  

  ध्यान दिनुहोस् कि दृश्य view_with_unionall छिटो रिफ्रेसको लागि आवश्यकताहरू पूरा गर्दछ।

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

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

• यो SELECT प्रत्येक प्रश्नको सूचीमा समावेश हुनुपर्छ UNION ALL मार्कर, र UNION ALL स्तम्भमा प्रत्येकमा फरक स्थिर संख्यात्मक वा स्ट्रिङ मान हुनुपर्छ UNION ALL साखा। यसबाहेक, मार्कर स्तम्भ एउटै क्रमबद्ध स्थितिमा देखा पर्दछ SELECT प्रत्येक क्वेरी ब्लकको सूची। हेर्नुहोस्"UNION ALL मार्कर र क्वेरी पुन: लेख्नुहोस्» सम्बन्धमा थप जानकारीको लागि UNION ALL मार्करहरू
• केहि सुविधाहरू जस्तै बाहिरी जोडहरू, सम्मिलित-मात्र समग्र भौतिक दृश्य क्वेरीहरू र रिमोट तालिकाहरू भौतिक दृश्यहरूको लागि समर्थित छैनन्। UNION ALL। नोट गर्नुहोस्, तथापि, प्रतिकृतिमा प्रयोग गरिएका भौतिक दृश्यहरू, जसमा जोडिहरू वा समुच्चयहरू समावेश हुँदैनन्, चाँडै रिफ्रेस गर्न सकिन्छ जब UNION ALL वा टाढाको तालिकाहरू प्रयोग गरिन्छ।
• संगतता प्रारम्भिक प्यारामिटर 9.2.0 वा उच्च मा एक छिटो रिफ्रेस योग्य भौतिक दृश्य सिर्जना गर्न सेट हुनुपर्छ। UNION ALL.

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

माईक्रोसफ्ट SQL सर्वर

थप आवश्यकताहरू

SET विकल्पहरू र deterministic प्रकार्य आवश्यकताहरूको अतिरिक्त, निम्न आवश्यकताहरू पूरा गर्नुपर्छ:

• कार्यान्वयन गर्ने प्रयोगकर्ता CREATE INDEX दृश्यको मालिक हुनुपर्छ।
• जब तपाइँ अनुक्रमणिका सिर्जना गर्नुहुन्छ, the IGNORE_DUP_KEY विकल्प बन्द (पूर्वनिर्धारित सेटिङ) मा सेट हुनुपर्छ।
• तालिकाहरू दुई-भाग नामहरूद्वारा सन्दर्भ हुनुपर्छ, योजना.तालिका नाम दृश्य परिभाषा मा।
• दृश्यमा सन्दर्भ गरिएका प्रयोगकर्ता-परिभाषित प्रकार्यहरू प्रयोग गरेर सिर्जना गर्नुपर्छ WITH SCHEMABINDING विकल्प।
• दृश्यमा सन्दर्भ गरिएका कुनै पनि प्रयोगकर्ता-परिभाषित प्रकार्यहरू दुई-भाग नामहरूद्वारा सन्दर्भ हुनुपर्छ, ..
• प्रयोगकर्ता-परिभाषित प्रकार्यको डेटा पहुँच गुण हुनुपर्छ NO SQL, र बाह्य पहुँच सम्पत्ति हुनुपर्छ NO.
• सामान्य भाषा रनटाइम (CLR) प्रकार्यहरू दृश्यको चयन सूचीमा देखा पर्न सक्छ, तर क्लस्टर गरिएको अनुक्रमणिका कुञ्जीको परिभाषाको अंश हुन सक्दैन। CLR प्रकार्यहरू दृश्यको WHERE खण्ड वा दृश्यमा JOIN सञ्चालनको ON खण्डमा देखा पर्न सक्दैन।
• CLR प्रकार्यहरू र दृश्य परिभाषामा प्रयोग गरिएका CLR प्रयोगकर्ता-परिभाषित प्रकारहरूको विधिहरूमा निम्न तालिकामा देखाइएका गुणहरू सेट हुनुपर्छ।

  सम्पत्ति
  नोट

  DETERMINISTIC = सत्य
  Microsoft .NET फ्रेमवर्क विधिको विशेषताको रूपमा स्पष्ट रूपमा घोषणा गरिनुपर्छ।

  PRECISE = सत्य
  .NET फ्रेमवर्क विधिको विशेषताको रूपमा स्पष्ट रूपमा घोषणा गरिनुपर्छ।

  डाटा पहुँच = कुनै SQL छैन
  DataAccessKind.None मा DataAccess विशेषता र SystemDataAccessKind.None मा SystemDataAccess विशेषता सेट गरेर निर्धारण गरिन्छ।

  बाह्य पहुँच = छैन
  यो गुण CLR दिनचर्याका लागि NO मा पूर्वनिर्धारित छ।

• दृश्य प्रयोग गरेर सिर्जना गर्नुपर्छ WITH SCHEMABINDING विकल्प।
• दृश्यले केवल आधार तालिकाहरू सन्दर्भ गर्नुपर्छ जुन दृश्यको रूपमा एउटै डेटाबेसमा छन्। दृश्यले अन्य दृश्यहरूलाई सन्दर्भ गर्न सक्दैन।
• दृश्य परिभाषामा SELECT कथनले निम्न Transact-SQL तत्वहरू समावेश गर्नु हुँदैन:

  COUNT
  ROWSET प्रकार्यहरू (OPENDATASOURCE, OPENQUERY, OPENROWSET, र OPENXML)
  OUTER जोडिन्छ(LEFT, RIGHTवा FULL)

  व्युत्पन्न तालिका (निर्दिष्ट द्वारा परिभाषित a SELECT मा बयान FROM खण्ड)
  स्वयम् जोडिन्छ
  प्रयोग गरेर स्तम्भहरू निर्दिष्ट गर्दै SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARPवा AVG
  साझा तालिका अभिव्यक्ति (CTE)

  फ्लोट1, पाठ, ntext, छवि, XMLवा फाइलस्ट्रिम स्तम्भहरू
  सबक्वेरी
  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 अवस्थित छ, दृश्य परिभाषा समावेश हुनुपर्छ COUNT_BIG(*) र समावेश हुनु हुँदैन HAVING। यी GROUP BY प्रतिबन्धहरू अनुक्रमित दृश्य परिभाषामा मात्र लागू हुन्छन्। एक क्वेरीले यसको कार्यान्वयन योजनामा ​​अनुक्रमित दृश्य प्रयोग गर्न सक्छ यदि यसले यी कुराहरू पूरा गर्दैन भने पनि GROUP BY प्रतिबन्धहरू।
• यदि दृश्य परिभाषाले a समावेश गर्दछ GROUP BY खण्ड, अद्वितीय क्लस्टर गरिएको अनुक्रमणिकाको कुञ्जीले मा निर्दिष्ट स्तम्भहरूलाई मात्र सन्दर्भ गर्न सक्छ GROUP BY खण्ड

यो यहाँ स्पष्ट छ कि भारतीयहरू संलग्न थिएनन्, किनभने तिनीहरूले यो योजना अनुसार गर्ने निर्णय गरे "हामी थोरै, तर राम्रो गर्नेछौं।" त्यो हो, तिनीहरूसँग मैदानमा धेरै खानहरू छन्, तर तिनीहरूको स्थान अधिक पारदर्शी छ। सबैभन्दा निराशाजनक कुरा यो सीमा हो:

दृश्यले केवल आधार तालिकाहरू सन्दर्भ गर्नुपर्छ जुन दृश्यको रूपमा एउटै डेटाबेसमा छन्। दृश्यले अन्य दृश्यहरूलाई सन्दर्भ गर्न सक्दैन।

हाम्रो शब्दावलीमा, यसको मतलब एउटा प्रकार्यले अर्को भौतिक कार्यमा पहुँच गर्न सक्दैन। यसले कोलीमा रहेका सबै विचारधारालाई काट्छ।
साथै, यो सीमा (र पाठमा थप) ले प्रयोगका केसहरूलाई धेरै कम गर्छ:

दृश्य परिभाषामा SELECT कथनले निम्न Transact-SQL तत्वहरू समावेश गर्नु हुँदैन:

COUNT
ROWSET प्रकार्यहरू (OPENDATASOURCE, OPENQUERY, OPENROWSET, र OPENXML)
OUTER जोडिन्छ(LEFT, RIGHTवा FULL)

व्युत्पन्न तालिका (निर्दिष्ट द्वारा परिभाषित a SELECT मा बयान FROM खण्ड)
स्वयम् जोडिन्छ
प्रयोग गरेर स्तम्भहरू निर्दिष्ट गर्दै SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARPवा AVG
साझा तालिका अभिव्यक्ति (CTE)

फ्लोट1, पाठ, ntext, छवि, XMLवा फाइलस्ट्रिम स्तम्भहरू
सबक्वेरी
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

OUTER JOINS, UNION, ORDER BY र अरूलाई निषेध गरिएको छ। के प्रयोग गर्न नसकिने भन्दा के प्रयोग गर्न सकिन्छ भनेर निर्दिष्ट गर्न सजिलो हुन सक्छ। सूची सायद धेरै छोटो हुनेछ।

संक्षेपमा: LGPL टेक्नोलोजीमा DBMS बनाम कुनै पनि (एक तार्किक, प्राविधिक अपवाद बाहेक) प्रत्येकमा प्रतिबन्धहरूको ठूलो सेट (व्यावसायिक नोट गरौं)। यद्यपि, यो ध्यान दिनु पर्छ कि यस संयन्त्रलाई रिलेशनल तर्कमा लागू गर्न वर्णन गरिएको कार्यात्मक तर्कमा भन्दा केहि बढी गाह्रो छ।

कार्यान्वयन

यसले कसरी काम गर्छ? PostgreSQL लाई "भर्चुअल मेसिन" को रूपमा प्रयोग गरिन्छ। त्यहाँ भित्र एउटा जटिल एल्गोरिथ्म छ जसले प्रश्नहरू निर्माण गर्दछ। यहाँ मुहान। र त्यहाँ ifs को एक गुच्छा संग heuristics को एक ठूलो सेट मात्र छैन। त्यसोभए, यदि तपाइँसँग अध्ययन गर्न केहि महिना छ भने, तपाइँ वास्तुकला बुझ्न प्रयास गर्न सक्नुहुन्छ।

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

निम्न लेखहरूमा, म तपाइँ कसरी प्रकार्यहरूमा प्रतिबन्धहरू सेट गर्न सक्नुहुन्छ, परिवर्तन सत्रहरूसँग काम गर्न सक्नुहुन्छ, र धेरै कुराहरू बारे पनि कुरा गर्नेछु।

स्रोत: www.habr.com