ბალანსი წერს და კითხულობს მონაცემთა ბაზაში

წინა მუხლი მე აღვწერე მონაცემთა ბაზის კონცეფცია და განხორციელება, რომელიც აგებულია ფუნქციებზე და არა ცხრილებსა და ველებზე, როგორც რელაციურ მონაცემთა ბაზებში. მასში მოცემულია მრავალი მაგალითი, რომელიც აჩვენებს ამ მიდგომის უპირატესობას კლასიკურთან შედარებით. ბევრი აღმოჩნდა, რომ ისინი საკმარისად დამაჯერებელი არ იყო.

ამ სტატიაში მე გაჩვენებთ, თუ როგორ საშუალებას გაძლევთ სწრაფად და მოხერხებულად დააბალანსოთ ჩანაწერები და წაკითხვები მონაცემთა ბაზაში ოპერაციული ლოგიკის ცვლილების გარეშე. მსგავსი ფუნქციონალობის დანერგვა სცადეს თანამედროვე კომერციულ DBMS-ებში (კერძოდ, 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-ში იქნება ექვივალენტური O (თანამშრომლების რაოდენობა)რადგან ეს გაანგარიშება მოითხოვს თანამშრომლების მთელი ცხრილის სკანირებას და შემდეგ დაჯგუფებას დეპარტამენტების მიხედვით. ასევე იქნება მცირე (ჩვენ გვჯერა, რომ უფრო მეტი თანამშრომელია ვიდრე დეპარტამენტები) დანამატი არჩეული გეგმის მიხედვით O (თანამშრომლების რიცხვი) ან O (განყოფილებების რაოდენობა) დაჯგუფებისთვის და ა.შ.

ნათელია, რომ შესრულების ზედნადები შეიძლება განსხვავებული იყოს სხვადასხვა DBMS-ებში, მაგრამ სირთულე არანაირად არ შეიცვლება.

შემოთავაზებულ განხორციელებაში, ფუნქციური DBMS წარმოქმნის ერთ ქვემოთხოვნას, რომელიც გამოთვლის საჭირო მნიშვნელობებს დეპარტამენტისთვის და შემდეგ გააკეთებს JOIN განყოფილების ცხრილს სახელის მისაღებად. თუმცა, თითოეული ფუნქციისთვის, დეკლარაციისას, შესაძლებელია სპეციალური MATERIALIZED მარკერის დაყენება. სისტემა ავტომატურად შექმნის შესაბამის ველს თითოეული ასეთი ფუნქციისთვის. ფუნქციის მნიშვნელობის შეცვლისას, იმავე ტრანზაქციაში შეიცვლება ველის მნიშვნელობაც. ამ ფუნქციაზე წვდომისას, წინასწარ გამოთვლილ ველზე წვდომა მოხდება.

კერძოდ, თუ დააყენეთ MATERIALIZED ფუნქციებისთვის ითვლის თანამშრომლებს и ხელფასი ჯამი, შემდეგ ცხრილს დაემატება ორი ველი განყოფილებების სიით, სადაც შეინახება თანამშრომელთა რაოდენობა და მათი ჯამური ხელფასი. როდესაც ხდება თანამშრომლების, მათი ხელფასების ან განყოფილების კუთვნილების ცვლილება, სისტემა ავტომატურად შეცვლის ამ ველების მნიშვნელობებს. ზემოთ მოყვანილი მოთხოვნა პირდაპირ წვდება ამ ველებს და შესრულდება O (განყოფილებების რაოდენობა).

რა არის შეზღუდვები? მხოლოდ ერთი რამ: ასეთ ფუნქციას უნდა ჰქონდეს შეყვანის მნიშვნელობების სასრული რაოდენობა, რისთვისაც განისაზღვრება მისი მნიშვნელობა. წინააღმდეგ შემთხვევაში, შეუძლებელი იქნება ცხრილის აშენება, რომელიც ინახავს მის ყველა მნიშვნელობას, რადგან არ შეიძლება იყოს ცხრილი უსასრულო რაოდენობის რიგებით.

მაგალითი:

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, 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);


არ იქნება CTE SQL მოთხოვნაში. ამის ნაცვლად იქნება მარტივი GROUP BY.

ამ მექანიზმის გამოყენებით, თქვენ ასევე შეგიძლიათ მარტივად მოახდინოთ მონაცემთა ბაზის დენორმალიზება საჭიროების შემთხვევაში:

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

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


ფუნქციის გამოძახებისას თარიღი შეკვეთის ხაზისთვის, ველი, რომლისთვისაც არის ინდექსი, წაიკითხება ცხრილიდან შეკვეთის ხაზებით. როდესაც შეკვეთის თარიღი შეიცვლება, სისტემა ავტომატურად გადათვლის დენორმალიზებულ თარიღს ხაზში.

უპირატესობები

რისთვის არის მთელი ეს მექანიზმი? კლასიკურ DBMS-ებში, მოთხოვნების გადაწერის გარეშე, დეველოპერს ან DBA-ს შეუძლია შეცვალოს მხოლოდ ინდექსები, განსაზღვროს სტატისტიკა და უთხრას შეკითხვის დამგეგმავს, როგორ შეასრულოს ისინი (და HINT ხელმისაწვდომია მხოლოდ კომერციულ DBMS-ებში). რაც არ უნდა ეცადონ, ისინი ვერ შეძლებენ შეასრულონ პირველი შეკითხვა სტატიაში O (განყოფილებების რაოდენობა) მოთხოვნების შეცვლის ან ტრიგერების დამატების გარეშე. შემოთავაზებულ სქემაში, განვითარების ეტაპზე თქვენ არ გჭირდებათ ფიქრი მონაცემთა შენახვის სტრუქტურაზე და რომელი აგრეგაციების გამოყენებაზე. ეს ყველაფერი მარტივად შეიძლება შეიცვალოს ფრენისას, უშუალოდ ექსპლუატაციაში.

პრაქტიკაში ასე გამოიყურება. ზოგიერთი ადამიანი ავითარებს ლოგიკას პირდაპირ დავალებების საფუძველზე. მათ არ ესმით ალგორითმები და მათი სირთულე, შესრულების გეგმები, შეერთების ტიპები ან სხვა ტექნიკური კომპონენტი. ეს ადამიანები უფრო ბიზნეს ანალიტიკოსები არიან, ვიდრე დეველოპერები. შემდეგ, ეს ყველაფერი გადადის ტესტირებაში ან ექსპლუატაციაში. ჩართავს გრძელვადიანი მოთხოვნების აღრიცხვას. როდესაც გრძელი მოთხოვნა აღმოჩენილია, მაშინ სხვა ადამიანები (უფრო ტექნიკური - ძირითადად DBA) გადაწყვეტენ ჩართონ MATERIALIZED ზოგიერთ შუალედურ ფუნქციაზე. ეს ოდნავ ანელებს ჩაწერას (რადგან ის მოითხოვს ტრანზაქციის დამატებითი ველის განახლებას). თუმცა, არა მხოლოდ ეს შეკითხვა მნიშვნელოვნად დაჩქარებულია, არამედ ყველა სხვა, ვინც იყენებს ამ ფუნქციას. ამავდროულად, იმის გადაწყვეტა, თუ რომელი ფუნქციის მატერიალიზება უნდა მოხდეს, შედარებით მარტივია. ორი ძირითადი პარამეტრი: შესაძლო შეყვანის მნიშვნელობების რაოდენობა (ეს არის რამდენი ჩანაწერი იქნება შესაბამის ცხრილში) და რამდენად ხშირად გამოიყენება სხვა ფუნქციებში.

ანალოგები

თანამედროვე კომერციულ DBMS-ებს აქვთ მსგავსი მექანიზმები: მატერიალიზებული ხედვა FAST REFRESH (Oracle) და INDEXED VIEW (Microsoft SQL Server). PostgreSQL-ში, MATERIALIZED VIEW არ შეიძლება განახლდეს ტრანზაქციაში, მაგრამ მხოლოდ მოთხოვნით (და თუნდაც ძალიან მკაცრი შეზღუდვებით), ამიტომ ჩვენ არ განვიხილავთ მას. მაგრამ მათ აქვთ რამდენიმე პრობლემა, რაც მნიშვნელოვნად ზღუდავს მათ გამოყენებას.

პირველ რიგში, მატერიალიზაციის ჩართვა შეგიძლიათ მხოლოდ იმ შემთხვევაში, თუ უკვე შექმენით ჩვეულებრივი VIEW. წინააღმდეგ შემთხვევაში, ამ მატერიალიზაციის გამოსაყენებლად მოგიწევთ დარჩენილი მოთხოვნების გადაწერა ახლად შექმნილ ხედზე წვდომისთვის. ან დატოვეთ ყველაფერი ისე, როგორც არის, მაგრამ ეს მაინც არაეფექტური იქნება, თუ არის გარკვეული უკვე წინასწარ გამოთვლილი მონაცემები, მაგრამ ბევრი მოთხოვნა ყოველთვის არ იყენებს მას, არამედ ხელახლა გამოთვლა.

მეორეც, მათ აქვთ დიდი რაოდენობით შეზღუდვები:

Oracle

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) უნდა იყოს წარმოდგენილი. 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 პუნქტი შეიძლება სწრაფად განახლდეს იმ პირობით, რომ ხედები შეიძლება მთლიანად გაერთიანდეს. ინფორმაციისთვის, თუ რომელი ხედები გაერთიანდება, იხ Oracle მონაცემთა ბაზის 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 შეიძლება იყოს ქვემოთხოვნაში FROM პუნქტი იმ პირობით, რომ განმსაზღვრელი მოთხოვნა არის ფორმის SELECT * FROM (ნახვა ან ქვემოკითხვა ერთად UNION ALL) როგორც შემდეგ მაგალითში:

  შექმენით ხედვა view_with_unionall AS
  (SELECT c.rowid crid, c.cust_id, 2 umarker
   კლიენტებიდან c WHERE c.cust_last_name = 'სმიტი'
   UNION ALL
   აირჩიეთ c.rowid crid, c.cust_id, 3 umarker
   კლიენტებიდან c WHERE c.cust_last_name = 'ჯონსი');
  
  შექმენით მატერიალიზებული ხედი unionall_inside_view_mv
  განაახლეთ სწრაფად მოთხოვნით, როგორც
  SELECT * FROM view_with_unionall;
  

  გაითვალისწინეთ, რომ ხედი view_with_unionall აკმაყოფილებს სწრაფი განახლების მოთხოვნებს.

• თითოეული შეკითხვის ბლოკი UNION ALL მოთხოვნა უნდა აკმაყოფილებდეს სწრაფად განახლებადი მატერიალიზებული ხედის მოთხოვნებს აგრეგატებით ან სწრაფად განახლებადი მატერიალიზებული ხედის შეერთებით.

  შესაბამისი მატერიალიზებული ხედვის ჟურნალი უნდა შეიქმნას ცხრილებზე, როგორც ეს საჭიროა შესაბამისი ტიპის სწრაფად განახლებადი მატერიალიზებული ხედისთვის.
  გაითვალისწინეთ, რომ Oracle მონაცემთა ბაზა ასევე საშუალებას აძლევს ცალკეული ცხრილის მატერიალიზებულ ხედს, შეერთებით მხოლოდ გათვალისწინებული 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.

არ მინდა Oracle-ის გულშემატკივრების შეურაცხყოფა, მაგრამ მათი შეზღუდვების სიიდან თუ ვიმსჯელებთ, როგორც ჩანს, ეს მექანიზმი დაიწერა არა ზოგადად, რაღაც მოდელის გამოყენებით, არამედ ათასობით ინდიელის მიერ, სადაც ყველას მიეცა შესაძლებლობა. დაწერეს საკუთარი ფილიალი და თითოეულმა გააკეთა ის, რაც შეეძლო და გააკეთა. რეალური ლოგიკით ამ მექანიზმის გამოყენება ნაღმზე სიარულის მსგავსია. თქვენ შეგიძლიათ მიიღოთ ნაღმი ნებისმიერ დროს, ერთ-ერთი არააშკარა შეზღუდვის დაჭერით. როგორ მუშაობს ის ასევე ცალკე საკითხია, მაგრამ ეს სცილდება ამ სტატიის ფარგლებს.

Microsoft SQL Server

Დამატებითი მოთხოვნები

გარდა SET პარამეტრებისა და დეტერმინისტული ფუნქციის მოთხოვნებისა, უნდა დაკმაყოფილდეს შემდეგი მოთხოვნები:

• მომხმარებელი, რომელიც ასრულებს CREATE INDEX უნდა იყოს ხედის მფლობელი.
• როდესაც თქვენ შექმნით ინდექსს, IGNORE_DUP_KEY პარამეტრი უნდა იყოს დაყენებული OFF-ზე (ნაგულისხმევი პარამეტრი).
• ცხრილები უნდა იყოს მითითებული ორნაწილიანი სახელებით, სქემა.მაგიდის სახელი ხედვის განმარტებაში.
• მომხმარებლის მიერ განსაზღვრული ფუნქციები, რომლებიც მითითებულია ხედში, უნდა შეიქმნას გამოყენებით WITH SCHEMABINDING ვარიანტი.
• ხედში მითითებული მომხმარებლის მიერ განსაზღვრული ნებისმიერი ფუნქცია უნდა იყოს მითითებული ორნაწილიანი სახელებით, ..
• მომხმარებლის მიერ განსაზღვრული ფუნქციის მონაცემთა წვდომის თვისება უნდა იყოს NO SQL, და გარე წვდომის თვისება უნდა იყოს NO.
• საერთო ენის გაშვების დროის (CLR) ფუნქციები შეიძლება გამოჩნდეს ხედის შერჩეულ სიაში, მაგრამ არ შეიძლება იყოს კლასტერული ინდექსის კლავიშის განმარტების ნაწილი. CLR ფუნქციები არ შეიძლება გამოჩნდეს ხედის WHERE პუნქტში ან ხედში JOIN ოპერაციის ON პუნქტში.
• CLR ფუნქციებს და CLR მომხმარებლის მიერ განსაზღვრული ტიპების მეთოდებს, რომლებიც გამოიყენება ხედის განსაზღვრაში, უნდა ჰქონდეს თვისებები დაყენებული, როგორც ნაჩვენებია შემდეგ ცხრილში.

  გალერეა
  შენიშვნა

  დეტერმინისტული = ჭეშმარიტი
  აშკარად უნდა იყოს გამოცხადებული, როგორც Microsoft .NET Framework მეთოდის ატრიბუტი.

  ზუსტი = ჭეშმარიტი
  აშკარად უნდა იყოს გამოცხადებული, როგორც .NET Framework მეთოდის ატრიბუტი.

  მონაცემთა წვდომა = NO SQL
  განისაზღვრება DataAccess ატრიბუტის დაყენებით DataAccessKind.None და SystemDataAccess ატრიბუტი SystemDataAccessKind.None-ზე.

  გარე წვდომა = არა
  ეს თვისება ნაგულისხმევად არის NO CLR რუტინებისთვის.

• ხედი უნდა შეიქმნას გამოყენებით 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)

  float1, ტექსტი, ntext, სურათი, XML, ან ფაილის ნაკადი სვეტების
  subquery
  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

  მწირი სვეტების ნაკრები
  Inline (TVF) ან მრავალ განცხადების ცხრილის ღირებულების ფუნქციები (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 ინდექსირებული ხედი შეიძლება შეიცავდეს float სვეტები; თუმცა, ასეთი სვეტები არ შეიძლება იყოს ჩართული კლასტერული ინდექსის გასაღებში.

• 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)

float1, ტექსტი, ntext, სურათი, XML, ან ფაილის ნაკადი სვეტების
subquery
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

მწირი სვეტების ნაკრები
Inline (TVF) ან მრავალ განცხადების ცხრილის ღირებულების ფუნქციები (MSTVF)
OFFSET

CHECKSUM_AGG

აკრძალულია გარე შეერთება, UNION, ORDER BY და სხვა. შესაძლოა უფრო ადვილი ყოფილიყო იმის დაზუსტება, თუ რისი გამოყენება შეიძლებოდა, ვიდრე რა არ შეიძლება. სია ალბათ გაცილებით მცირე იქნება.

შეჯამება: შეზღუდვების უზარმაზარი ნაკრები LGPL ტექნოლოგიაში ყველა (მოდით აღვნიშნოთ კომერციული) DBMS-ის წინააღმდეგ (გარდა ერთი ლოგიკური, არა ტექნიკური). თუმცა, უნდა აღინიშნოს, რომ ამ მექანიზმის დანერგვა რელაციურ ლოგიკაში გარკვეულწილად უფრო რთულია, ვიდრე აღწერილ ფუნქციურ ლოგიკაში.

Реализация

Როგორ მუშაობს? PostgreSQL გამოიყენება როგორც "ვირტუალური მანქანა". შიგნით არის რთული ალგორითმი, რომელიც ქმნის შეკითხვებს. Აქ წყარო. და არ არის მხოლოდ ევრისტიკის დიდი ნაკრები, თუ არა. ასე რომ, თუ თქვენ გაქვთ რამდენიმე თვე შესასწავლად, შეგიძლიათ სცადოთ არქიტექტურის გაგება.

ეფექტურად მუშაობს? საკმაოდ ეფექტური. სამწუხაროდ, ამის დამტკიცება რთულია. შემიძლია მხოლოდ ვთქვა, რომ თუ გავითვალისწინებთ ათასობით მოთხოვნას, რომელიც არსებობს დიდ აპლიკაციებში, მაშინ საშუალოდ ისინი უფრო ეფექტურია, ვიდრე კარგი დეველოპერები. შესანიშნავ SQL პროგრამისტს შეუძლია დაწეროს ნებისმიერი შეკითხვა უფრო ეფექტურად, მაგრამ ათასი შეკითხვით მას უბრალოდ არ ექნება მოტივაცია ან დრო ამის გასაკეთებლად. ერთადერთი, რაც ახლა შემიძლია მოვიყვანო ეფექტურობის დამადასტურებლად არის ის, რომ რამდენიმე პროექტი მუშაობს ამ DBMS-ზე აგებულ პლატფორმაზე. ERP სისტემები, რომლებსაც აქვთ ათასობით სხვადასხვა მატერიალიზებული ფუნქცია, ათასობით მომხმარებელი და ტერაბაიტი მონაცემთა ბაზები ასობით მილიონი ჩანაწერით, რომლებიც გაშვებულია ორპროცესორიან ჩვეულებრივ სერვერზე. თუმცა, ნებისმიერს შეუძლია ჩამოტვირთვის გზით შეამოწმოს/უარყოს ეფექტურობა პლატფორმა და PostgreSQL, ჩართული შესვლა SQL მოთხოვნების და ცდილობს შეცვალოს ლოგიკა და მონაცემები იქ.

შემდეგ სტატიებში მე ასევე ვისაუბრებ იმაზე, თუ როგორ შეგიძლიათ დააწესოთ შეზღუდვები ფუნქციებზე, იმუშაოთ ცვლილებების სესიებზე და მრავალი სხვა.

წყარო: www.habr.com