ProHoster > Blogs > Administrācija > RakstÄ«Å”anas un lasÄ«Å”anas lÄ«dzsvaroÅ”ana datu bāzē

RakstÄ«Å”anas un lasÄ«Å”anas lÄ«dzsvaroÅ”ana datu bāzē

RakstÄ«Å”anas un lasÄ«Å”anas lÄ«dzsvaroÅ”ana datu bāzē
IepriekŔējā raksts Es aprakstÄ«ju tādas datu bāzes koncepciju un ievieÅ”anu, kas veidota, pamatojoties uz funkcijām, nevis tabulām un laukiem kā relāciju datu bāzēs. Tajā tika sniegti daudzi piemēri, kas parāda Ŕīs pieejas priekÅ”rocÄ«bas salÄ«dzinājumā ar klasisko. Daudzi uzskatÄ«ja, ka tie nav pietiekami pārliecinoÅ”i.

Å ajā rakstā es parādÄ«Å”u, kā Ŕī koncepcija ļauj ātri un ērti lÄ«dzsvarot rakstÄ«Å”anu un nolasÄ«Å”anu datubāzē, nemainot darbÄ«bas loÄ£iku. LÄ«dzÄ«gu funkcionalitāti ir mēģināts ieviest mÅ«sdienu komerciālajās DBVS (jo Ä«paÅ”i Oracle un Microsoft SQL Server). Raksta beigās parādÄ«Å”u, ka tas, ko viņi izdarÄ«ja, maigi izsakoties, nav Ä«sti izdevies.

Apraksts

Tāpat kā iepriekÅ”, labākas izpratnes labad aprakstu sākÅ”u ar piemēriem. Teiksim, ir jāievieÅ” loÄ£ika, kas atgriezÄ«s nodaļu sarakstu ar tajās esoÅ”o darbinieku skaitu un kopējo algu.

Funkcionālā datu bāzē tas izskatÄ«tos Ŕādi:

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

Å Ä« vaicājuma izpildes sarežģītÄ«ba jebkurā DBVS bÅ«s lÄ«dzvērtÄ«ga O (darbinieku skaits)jo Å”im aprēķinam ir nepiecieÅ”ams skenēt visu darbinieku tabulu un pēc tam tos grupēt pa departamentiem. BÅ«s arÄ« kāds neliels (uzskatām, ka darbinieku ir daudz vairāk nekā nodaļās) pielikums atkarÄ«bā no izvēlētā plāna O (darbinieku skaits žurnālā) vai O (nodaļu skaits) grupÄ“Å”anai un tā tālāk.

Ir skaidrs, ka izpildes pieskaitāmās izmaksas dažādās DBVS var atŔķirties, taču sarežģītība nekādā veidā nemainīsies.

Ierosinātajā realizācijā funkcionālā DBVS Ä£enerēs vienu apakÅ”vaicājumu, kas aprēķinās nodaļai nepiecieÅ”amās vērtÄ«bas un pēc tam izveidos JOIN ar nodaļas tabulu, lai iegÅ«tu nosaukumu. Taču katrai funkcijai, deklarējot, ir iespējams uzstādÄ«t Ä«paÅ”u MATERIALIZĒTA marÄ·ieri. Sistēma automātiski izveidos atbilstoÅ”u lauku katrai Ŕādai funkcijai. Mainot funkcijas vērtÄ«bu, tajā paŔā darÄ«jumā mainÄ«sies arÄ« lauka vērtÄ«ba. Piekļūstot Å”ai funkcijai, tiks piekļūts iepriekÅ” aprēķinātajam laukam.

Jo Ä«paÅ”i, ja funkcijām iestatāt MATERIALIZED skaitÄ«tDarbiniekus Šø algaSumma, tad tabulai ar nodaļu sarakstu tiks pievienoti divi lauki, kuros tiks saglabāts darbinieku skaits un viņu kopējā alga. Ikreiz, kad notiek darbinieku, viņu algu vai departamentu piederÄ«bas izmaiņas, sistēma automātiski mainÄ«s Å”o lauku vērtÄ«bas. IepriekÅ” minētais vaicājums tieÅ”i piekļūs Å”iem laukiem un tiks izpildÄ«ts O (nodaļu skaits).

Kādi ir ierobežojumi? Tikai viena lieta: Ŕādai funkcijai ir jābÅ«t ierobežotam skaitam ievades vērtÄ«bu, kurām ir noteikta tās vērtÄ«ba. Pretējā gadÄ«jumā nebÅ«s iespējams izveidot tabulu, kurā ir saglabātas visas tās vērtÄ«bas, jo nevar bÅ«t tabula ar bezgalÄ«gu rindu skaitu.

Piemērs:

employeesCount ā€˜ŠšŠ¾Š»ŠøчŠµŃŃ‚Š²Š¾ ŃŠ¾Ń‚Ń€ŃƒŠ“Š½ŠøŠŗŠ¾Š² Ń Š·Š°Ń€ŠæŠ»Š°Ń‚Š¾Š¹ > Nā€™ (Department d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;

Å Ä« funkcija ir definēta bezgalÄ«gam skaitam N vērtÄ«bu (piemēram, jebkura negatÄ«va vērtÄ«ba ir piemērota). Tāpēc uz tā nevar likt MATERIALIZĒTU. Tātad tas ir loÄ£isks, nevis tehnisks ierobežojums (tas ir, nevis tāpēc, ka mēs to nevarētu ieviest). Pretējā gadÄ«jumā ierobežojumu nav. Varat izmantot grupÄ“Å”anu, kārtoÅ”anu, UN un VAI, NODAÄ»A, rekursiju utt.

Piemēram, iepriekŔējā raksta 2.2. problēmā varat ievietot MATERIALIZED abām funkcijām:

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;

Sistēma pati izveidos vienu tabulu ar tipa taustiņiem Klients, Prece Šø VESELS SKAITLIS, pievienos tam divus laukus un atjauninās tajos esoŔās lauku vērtÄ«bas ar jebkādām izmaiņām. Kad tiks veikti turpmāki Å”o funkciju izsaukumi, tās netiks aprēķinātas, bet gan vērtÄ«bas tiks nolasÄ«tas no atbilstoÅ”ajiem laukiem.

Izmantojot Å”o mehānismu, jÅ«s varat, piemēram, atbrÄ«voties no rekursijām (CTE) vaicājumos. Jo Ä«paÅ”i apsveriet grupas, kas veido koku, izmantojot bērna/vecāku attiecÄ«bas (katrai grupai ir saite uz savu vecāku):

parent = DATA Group (Group);

Funkcionālā datu bāzē rekursijas loÄ£iku var norādÄ«t Ŕādi:

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;

Tā kā funkcijai isParent ir atzÄ«mēts MATERIALIZĒTS, tad tam tiks izveidota tabula ar diviem taustiņiem (grupām), kurā lauks isParent bÅ«s patiess tikai tad, ja pirmā atslēga ir otrās atslēga. Ierakstu skaits Å”ajā tabulā bÅ«s vienāds ar grupu skaitu, kas reizināts ar koka vidējo dziļumu. Ja jums ir nepiecieÅ”ams, piemēram, saskaitÄ«t noteiktas grupas pēcnācēju skaitu, varat izmantot Å”o funkciju:

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

SQL vaicājumā nebūs CTE. Tā vietā būs vienkārŔa GROUP BY.

Izmantojot Å”o mehānismu, varat arÄ« viegli denormalizēt datu bāzi, ja nepiecieÅ”ams:

CLASS Order 'Š—Š°ŠŗŠ°Š·';
date 'Š”Š°Ń‚Š°' = DATA DATE (Order);

CLASS OrderDetail 'Š”трŠ¾ŠŗŠ° Š·Š°ŠŗŠ°Š·Š°';
order 'Š—Š°ŠŗŠ°Š·' = DATA Order (OrderDetail);
date 'Š”Š°Ń‚Š°' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;

Izsaucot funkciju dati pasūtījuma rindai lauks, kuram ir indekss, tiks nolasīts no tabulas ar pasūtījuma rindām. Kad pasūtījuma datums mainās, sistēma pati automātiski pārrēķinās denormalizēto datumu rindā.

PriekŔrocības

Kam domāts viss Å”is mehānisms? Klasiskajās DBVS bez vaicājumu pārrakstÄ«Å”anas izstrādātājs vai DBA var mainÄ«t tikai indeksus, noteikt statistiku un norādÄ«t vaicājumu plānotājam, kā tos izpildÄ«t (un padomi ir pieejami tikai komerciālajās DBVS). NeatkarÄ«gi no tā, kā viņi censtos, viņi nevarēs izpildÄ«t pirmo vaicājumu rakstā O (nodaļu skaits) nemainot vaicājumus vai nepievienojot aktivizētājus. Piedāvātajā shēmā izstrādes stadijā nav jādomā par datu glabāŔanas struktÅ«ru un kādus apkopojumus izmantot. To visu var viegli mainÄ«t lidojumā, tieÅ”i ekspluatācijā.

Praksē tas izskatās Ŕādi. Daži cilvēki izstrādā loÄ£iku, pamatojoties tieÅ”i uz veicamo uzdevumu. Viņi nesaprot ne algoritmus un to sarežģītÄ«bu, ne izpildes plānus, ne savienojumu veidus, ne arÄ« citus tehniskos komponentus. Å ie cilvēki ir vairāk biznesa analÄ«tiÄ·i nekā izstrādātāji. Pēc tam tas viss tiek nodots testÄ“Å”anai vai ekspluatācijai. Iespējo ilgstoÅ”u vaicājumu reÄ£istrÄ“Å”anu. Kad tiek atklāts garÅ” vaicājums, citi cilvēki (tehniskāki ā€“ bÅ«tÄ«bā DBA) nolemj iespējot MATERIALIZED kādā starpfunkcijā. Tas nedaudz palēnina ierakstÄ«Å”anu (jo tam ir jāatjaunina papildu lauks darÄ«jumā). Tomēr ne tikai Å”is vaicājums ir ievērojami paātrināts, bet arÄ« visi citi, kas izmanto Å”o funkciju. Tajā paŔā laikā ir samērā viegli izlemt, kuru funkciju Ä«stenot. Divi galvenie parametri: iespējamo ievades vērtÄ«bu skaits (tas ir, cik ierakstu bÅ«s attiecÄ«gajā tabulā) un cik bieži tas tiek izmantots citās funkcijās.

Analogi

MÅ«sdienu komerciālajām DBVS ir lÄ«dzÄ«gi mehānismi: MATERIALIZĒTS SKATS ar FAST REFRESH (Oracle) un INDEXED VIEW (Microsoft SQL Server). PostgreSQL MATERIALIZED VIEW nevar atjaunināt darÄ«jumā, bet tikai pēc pieprasÄ«juma (un pat ar ļoti stingriem ierobežojumiem), tāpēc mēs to neuzskatām. Bet tiem ir vairākas problēmas, kas bÅ«tiski ierobežo to izmantoÅ”anu.

Pirmkārt, jÅ«s varat iespējot materializāciju tikai tad, ja jau esat izveidojis parasto SKATU. Pretējā gadÄ«jumā jums bÅ«s jāpārraksta atlikuÅ”ie pieprasÄ«jumi, lai piekļūtu jaunizveidotajam skatam, lai izmantotu Å”o materializāciju. Vai arÄ« atstāt visu kā ir, bet tas bÅ«s vismaz neefektÄ«vi, ja bÅ«s noteikti jau iepriekÅ” aprēķināti dati, bet daudzi vaicājumi ne vienmēr tos izmanto, bet pārrēķina.

Otrkārt, tiem ir milzīgs skaits ierobežojumu:

Orākuls

5.3.8.4. Vispārīgi ātrās atsvaidzināŔanas ierobežojumi

Materializētā skata definējoÅ”ais vaicājums ir ierobežots Ŕādi:

  • Materializētajā skatā nedrÄ«kst bÅ«t atsauces uz tādiem izteicieniem, kas neatkārtojas SYSDATE un ROWNUM.
  • Materializētajā skatā nedrÄ«kst bÅ«t atsauces uz RAW or LONG RAW datu tipi.
  • Tas nevar saturēt a SELECT saraksta apakÅ”vaicājums.
  • Tajā nedrÄ«kst bÅ«t analÄ«tiskas funkcijas (piemēram, RANK) iekÅ” SELECT klauzula.
  • Tas nevar atsaukties uz tabulu, uz kuras an XMLIndex indekss ir definēts.
  • Tas nevar saturēt a MODEL klauzula.
  • Tas nevar saturēt a HAVING klauzula ar apakÅ”vaicājumu.
  • Tas nevar saturēt ligzdotus vaicājumus, kuriem ir ANY, ALL, vai NOT EXISTS.
  • Tas nevar saturēt a [START WITH ā€¦] CONNECT BY klauzula.
  • Tajā nedrÄ«kst bÅ«t vairākas detalizētas tabulas dažādās vietnēs.
  • ON COMMIT materializētajos skatos nevar bÅ«t attālas detalizētas tabulas.
  • Ligzdotajiem materializētajiem skatiem ir jābÅ«t savienojumam vai apkopojumam.
  • Materializētie savienojuma skati un materializētie apkopotie skati ar a GROUP BY klauzulu nevar atlasÄ«t no indeksā sakārtotas tabulas.

5.3.8.5. Ierobežojumi ātrai atsvaidzināŔanai materializētos skatos ar tikai pievienoÅ”anos

Definējot vaicājumus materializētiem skatiem ar tikai savienojumiem un bez apkopojumiem, ir Ŕādi ātrās atsvaidzināŔanas ierobežojumi:

  • Visi ierobežojumi no Ā«VispārÄ«gi ātrās atsvaidzināŔanas ierobežojumi".
  • Viņiem nevar bÅ«t GROUP BY klauzulas vai apkopojumi.
  • Visu tabulu rindas FROM sarakstam ir jāparādās SELECT vaicājuma saraksts.
  • Materializētiem skata žurnāliem ir jābÅ«t ar rindām visām pamata tabulām FROM vaicājuma saraksts.
  • JÅ«s nevarat izveidot ātri atsvaidzināmu materializētu skatu no vairākām tabulām ar vienkārÅ”iem savienojumiem, kas ietver objekta tipa kolonnu SELECT paziņojums, apgalvojums.

Turklāt jÅ«su izvēlētā atsvaidzināŔanas metode nebÅ«s optimāli efektÄ«va, ja:

  • DefinējoÅ”ais vaicājums izmanto ārējo savienojumu, kas darbojas kā iekŔējais savienojums. Ja definējoÅ”ais vaicājums satur Ŕādu savienojumu, apsveriet definējoŔā vaicājuma pārrakstÄ«Å”anu, lai ietvertu iekŔējo savienojumu.
  • JÅ«su darbs IR Klientu apkalpoÅ”ana SELECT materializētā skata sarakstā ir izteiksmes vairāku tabulu kolonnās.

5.3.8.6. Ierobežojumi ātrai atsvaidzināŔanai materializētiem skatiem ar apkopojumiem

Definējot vaicājumus materializētiem skatiem ar apkopojumiem vai savienojumiem, ir Ŕādi ātrās atsvaidzināŔanas ierobežojumi.

Ātrā atsvaidzināŔana tiek atbalstÄ«ta abiem ON COMMIT un ON DEMAND materializēti viedokļi, tomēr tiek piemēroti Ŕādi ierobežojumi:

  • Visām tabulām materializētajā skatā ir jābÅ«t materializētā skata žurnāliem, un materializētā skata žurnāliem:
    • Ietver visas kolonnas no tabulas, uz kuru ir atsauce materializētajā skatā.
    • Norādiet ar ROWID un INCLUDING NEW VALUES.
    • norādiet SEQUENCE klauzulu, ja paredzams, ka tabulā bÅ«s ieliktņu/tieŔās ielādes, dzÄ“Å”anas un atjauninājumu kombinācija.

  • Tikai SUM, COUNT, AVG, STDDEV, VARIANCE, MIN un MAX tiek atbalstÄ«ti ātrai atsvaidzināŔanai.
  • COUNT(*) jāprecizē.
  • Apkopotajām funkcijām ir jābÅ«t tikai kā izteiksmes visattālākajai daļai. Tas ir, agregāti, piemēram, AVG(AVG(x)) or AVG(x)+ AVG(x) nav atļauts.
  • Par katru agregātu, piemēram, AVG(expr), atbilstoÅ”ais COUNT(expr) jābÅ«t klāt. Oracle to iesaka SUM(expr) jāprecizē.
  • If VARIANCE(expr) or STDDEV(expr) ir norādÄ«ts, COUNT(expr) un SUM(expr) jāprecizē. Oracle to iesaka SUM(expr *expr) jāprecizē.
  • JÅ«su darbs IR Klientu apkalpoÅ”ana SELECT kolonna definējoÅ”ajā vaicājumā nevar bÅ«t sarežģīta izteiksme ar kolonnām no vairākām bāzes tabulām. Iespējamais risinājums ir izmantot ligzdotu materializētu skatu.
  • JÅ«su darbs IR Klientu apkalpoÅ”ana SELECT sarakstā jāiekļauj viss GROUP BY kolonnas.
  • Materializētais skats nav balstÄ«ts uz vienu vai vairākām attālām tabulām.
  • Ja izmantojat CHAR datu tips materializētā skata žurnāla filtra kolonnās, galvenās vietnes un materializētā skata rakstzÄ«mju kopām ir jābÅ«t vienādām.
  • Ja materializētajam skatam ir kāds no Å”iem parametriem, ātrā atsvaidzināŔana tiek atbalstÄ«ta tikai parastajos DML ievietojumos un tieŔās ielādes.
    • Materializēti skati ar MIN or MAX agregāti
    • Materializēti skati, kuriem ir SUM(expr) bet nē COUNT(expr)
    • Materializēti skati bez COUNT(*)

    Šāds materializēts skats tiek saukts par tikai ievietoÅ”anas materializēto skatu.

  • Materializēts skats ar MAX or MIN ir ātri atsvaidzināms pēc dzÄ“Å”anas vai jauktiem DML priekÅ”rakstiem, ja tam nav a WHERE klauzula.
    Maksimālajai/minÅ«tei ātrajai atsvaidzināŔanai pēc dzÄ“Å”anas vai jaukta DML nav tāda pati darbÄ«ba kā tikai ievietoÅ”anas gadÄ«jumā. Tas dzÄ“Å” un atkārtoti aprēķina skarto grupu maksimālās/minÅ«tes vērtÄ«bas. Jums ir jāapzinās tā veiktspējas ietekme.
  • Materializēti skati ar nosauktiem skatiem vai apakÅ”vaicājumiem FROM klauzulu var ātri atsvaidzināt, ja skatus var pilnÄ«bā apvienot. Informāciju par to, kuri skati tiks apvienoti, skatiet Oracle datu bāzes SQL valodas atsauce.
  • Ja nav ārējo savienojumu, jums var bÅ«t patvaļīgas atlases un pievienoÅ”anās WHERE klauzula.
  • Materializēti apkopotie skati ar ārējiem savienojumiem ir ātri atsvaidzināmi pēc parastās DML un tieŔās ielādes, ja ir modificēta tikai ārējā tabula. Unikāliem ierobežojumiem ir jābÅ«t arÄ« iekŔējās savienoÅ”anas tabulas savienojuma kolonnās. Ja ir ārējie savienojumi, visi savienojumi ir jāsavieno ar ANDs un jāizmanto vienādÄ«ba (=) operators.
  • Materializētiem skatiem ar CUBE, ROLLUP, grupÄ“Å”anas kopas vai to savienoÅ”ana, tiek piemēroti Ŕādi ierobežojumi:
    • JÅ«su darbs IR Klientu apkalpoÅ”ana SELECT sarakstā jāiekļauj grupÄ“Å”anas atŔķirÄ«bas zÄ«me, kas var bÅ«t a GROUPING_ID funkcija uz visiem GROUP BY izteicieni vai GROUPING funkcijas katrai pa vienai GROUP BY izteiksme. Piemēram, ja GROUP BY materializētā skatÄ«juma klauzula ir "GROUP BY CUBE(a, b)", tad SELECT sarakstā jāiekļauj vai nu "GROUPING_ID(a, b)Ā» vai Ā«GROUPING(a) AND GROUPING(b)Ā» lai materializētais skats bÅ«tu ātri atjaunojams.
    • GROUP BY nedrÄ«kst radÄ«t dublētus grupējumus. Piemēram, "GROUP BY a, ROLLUP(a, b)"nav ātri atsvaidzināms, jo tas rada dublētus grupējumus"(a), (a, b), AND (a)".

5.3.8.7. Ierobežojumi ātrai atsvaidzināŔanai materializētos skatos, izmantojot UNION ALL

Materializēti skati ar UNION ALL iestatiet operatora atbalstu REFRESH FAST iespēja, ja ir izpildÄ«ti Ŕādi nosacÄ«jumi:

  • DefinējoÅ”ajam vaicājumam ir jābÅ«t UNION ALL operators augstākā lÄ«menÄ«.

    JÅ«su darbs IR Klientu apkalpoÅ”ana UNION ALL operatoru nevar iegult apakÅ”vaicājumā, ar vienu izņēmumu: The UNION ALL var bÅ«t apakÅ”vaicājumā FROM klauzula, ja definējoÅ”ais vaicājums ir Ŕādā formā SELECT * FROM (skatiet vai veiciet apakÅ”vaicājumu ar UNION ALL) kā Å”ajā piemērā:

    CREATE VIEW view_with_unionall AS (ATLASÄŖT c.rowid crid, c.cust_id, 2 umarker NO klientiem c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker NO klientiem c WHERE c.cust_last "Džounss"); IZVEIDOT MATERIALIZĒTU SKATU unionall_inside_view_mv PĒC PIEPRASÄŖJUMA ĀTRI ATSVAIDZINĀT, KĀ IZVĒLĒTIES * NO view_with_unionall;

    Ņemiet vērā, ka skats view_with_unionall atbilst ātras atsvaidzināŔanas prasÄ«bām.

  • Katrs vaicājumu bloks UNION ALL vaicājumam ir jāatbilst prasÄ«bām par ātri atsvaidzinoÅ”u materializētu skatu ar apkopojumiem vai ātri atsvaidzināma materializēta skata ar savienojumiem prasÄ«bām.

    Tabulās ir jāizveido atbilstoÅ”i materializētā skata žurnāli, kā nepiecieÅ”ams atbilstoÅ”ajam ātri atsvaidzināmā materializētā skata veidam.
    Ņemiet vērā, ka Oracle datu bāze pieļauj arÄ« atseviŔķas tabulas materializēta skata Ä«paÅ”o gadÄ«jumu ar savienojumiem tikai tad, ja ROWID kolonna ir iekļauta SELECT sarakstā un materializētā skata žurnālā. Tas tiek parādÄ«ts skata definējoÅ”ajā vaicājumā view_with_unionall.

  • JÅ«su darbs IR Klientu apkalpoÅ”ana SELECT katra vaicājuma sarakstā jāiekļauj a UNION ALL marÄ·ieris un UNION ALL katrā kolonnā ir jābÅ«t atŔķirÄ«gai konstantai skaitliskai vai virknes vērtÄ«bai UNION ALL filiāle. Turklāt marÄ·iera kolonnai ir jāparādās tajā paŔā kārtas pozÄ«cijā SELECT katra vaicājuma bloka saraksts. SkatÄ«t "UNION ALL MarÄ·ieris un vaicājums pārrakstÄ«tĀ» lai iegÅ«tu vairāk informācijas par UNION ALL marÄ·ieri.
  • Dažas funkcijas, piemēram, ārējie savienojumi, tikai ievietojami apkopotie materializēto skatu vaicājumi un attālās tabulas, netiek atbalstÄ«ti materializētiem skatiem ar UNION ALL. Tomēr ņemiet vērā, ka replicÄ“Å”anā izmantotos materializētos skatus, kas nesatur savienojumus vai apkopojumus, var ātri atsvaidzināt, kad UNION ALL vai tiek izmantotas attālās tabulas.
  • SaderÄ«bas inicializācijas parametram jābÅ«t iestatÄ«tam uz 9.2.0 vai augstāku, lai izveidotu ātri atsvaidzināmu materializētu skatu ar UNION ALL.

Negribu aizvainot Oracle fanus, bet, spriežot pēc viņu ierobežojumu saraksta, Ŕķiet, ka Å”is mehānisms ir rakstÄ«ts nevis vispārÄ«gā gadÄ«jumā, izmantojot kaut kādu modeli, bet gan tÅ«kstoÅ”iem indieÅ”u, kur katram tika dota iespēja uzraksta savu zaru, un katrs darÄ«ja, ko varēja.un darÄ«ja. Å Ä« mehānisma izmantoÅ”ana Ä«stai loÄ£ikai ir kā staigāŔana pa mÄ«nu lauku. JÅ«s varat iegÅ«t mÄ«nu jebkurā laikā, nospiežot kādu no acÄ«mredzamajiem ierobežojumiem. Tas, kā tas darbojas, ir arÄ« atseviŔķs jautājums, taču tas ir ārpus Ŕī raksta darbÄ«bas jomas.

Microsoft SQL Server

Papildu prasības

Papildus SET opcijām un deterministisku funkciju prasÄ«bām ir jāievēro Ŕādas prasÄ«bas:

  • Lietotājs, kurÅ” izpilda CREATE INDEX jābÅ«t skata Ä«paÅ”niekam.
  • Kad veidojat indeksu, IGNORE_DUP_KEY opcijai jābÅ«t iestatÄ«tai uz OFF (noklusējuma iestatÄ«jums).
  • Uz tabulām jābÅ«t atsaucēm ar divdaļīgiem nosaukumiem, shēma.tabulas nosaukums skata definÄ«cijā.
  • Skatā norādÄ«tās lietotāja definētās funkcijas ir jāizveido, izmantojot WITH SCHEMABINDING variants.
  • Visas lietotāja definētās funkcijas, uz kurām ir atsauce skatā, ir jāatsauc ar divdaļīgiem nosaukumiem, ..
  • Lietotāja definētas funkcijas datu piekļuves rekvizÄ«tam ir jābÅ«t NO SQL, un ārējās piekļuves Ä«paÅ”umam jābÅ«t NO.
  • Kopējās valodas izpildlaika (CLR) funkcijas var parādÄ«ties skata atlases sarakstā, taču tās nevar bÅ«t daļa no kopu indeksa atslēgas definÄ«cijas. CLR funkcijas nevar parādÄ«ties skata klauzulā WHERE vai skata darbÄ«bas JOIN klauzulā ON.
  • Skata definÄ«cijā izmantotajām CLR funkcijām un CLR lietotāja definēto tipu metodēm ir jābÅ«t iestatÄ«tām Ä«paŔībām, kā parādÄ«ts nākamajā tabulā.

    īpaŔums
    Piezīmes

    DETERMINISTISKS = TRUE
    Ir skaidri jānorāda kā Microsoft .NET Framework metodes atribūts.

    PRECÄŖZI = TRUE
    Ir skaidri jānorāda kā .NET Framework metodes atribūts.

    DATU PIEKĻUVE = NAV SQL
    Nosaka, iestatot DataAccess atribūtu DataAccessKind.None un SystemDataAccess atribūtu SystemDataAccessKind.None.

    ĀRĒJĀ PIEKĻUVE = NĒ
    Šis rekvizīts pēc noklusējuma ir NO CLR rutīnām.

  • Skats jāizveido, izmantojot WITH SCHEMABINDING variants.
  • Skatā jāatsaucas tikai uz bāzes tabulām, kas atrodas tajā paŔā datu bāzē kā skats. Skats nevar atsaukties uz citiem skatiem.
  • Skata definÄ«cijas priekÅ”raksts SELECT nedrÄ«kst saturēt Ŕādus Transact-SQL elementus:

    COUNT
    ROWSET funkcijas (OPENDATASOURCE, OPENQUERY, OPENROWSET, UN OPENXML)
    OUTER pievienojas (LEFT, RIGHT, vai FULL)

    Atvasināta tabula (definēta, norādot a SELECT paziņojums FROM klauzula)
    PaŔapvienojas
    Kolonnu norādīŔana, izmantojot SELECT * or SELECT <table_name>.*

    DISTINCT
    STDEV, STDEVP, VAR, VARP, vai AVG
    Kopējā tabulas izteiksme (CTE)

    peldēt1, teksts, ntext, attēls, XML, vai failu straume kolonnas
    ApakŔvaicājums
    OVER klauzula, kas ietver ranžēŔanas vai apkopojuma loga funkcijas

    Pilna teksta predikāti (CONTAINS, FREETEXT)
    SUM funkcija, kas atsaucas uz nullējamu izteiksmi
    ORDER BY

    CLR lietotāja definēta apkopoÅ”anas funkcija
    TOP
    CUBE, ROLLUP, vai GROUPING SETS Uzņēmējiem

    MIN, MAX
    UNION, EXCEPT, vai INTERSECT Uzņēmējiem
    TABLESAMPLE

    Tabulas mainīgie
    OUTER APPLY or CROSS APPLY
    PIVOT, UNPIVOT

    Reti kolonnu komplekti
    Iekļautās (TVF) vai vairāku priekÅ”rakstu tabulas vērtÄ«bas funkcijas (MSTVF)
    OFFSET

    CHECKSUM_AGG

    1 Indeksētajā skatā var bÅ«t peldēt kolonnas; tomēr Ŕādas kolonnas nevar iekļaut klasterizētā indeksa atslēgā.

  • If GROUP BY ir klāt, VIEW definÄ«cijā ir jāietver COUNT_BIG(*) un nedrÄ«kst saturēt HAVING. Å is GROUP BY ierobežojumi attiecas tikai uz indeksētā skata definÄ«ciju. Vaicājums izpildes plānā var izmantot indeksētu skatu, pat ja tas neatbilst Å”iem nosacÄ«jumiem GROUP BY ierobežojumi.
  • Ja skata definÄ«cija satur a GROUP BY klauzulu, unikālā klasterizētā indeksa atslēga var atsaukties tikai uz kolonnām, kas norādÄ«tas GROUP BY klauzula.

Å eit ir skaidrs, ka indieÅ”i nebija iesaistÄ«ti, jo viņi nolēma to darÄ«t saskaņā ar shēmu ā€œmēs darÄ«sim maz, bet labiā€. Tas ir, viņiem ir vairāk mÄ«nu uz lauka, bet to atraÅ”anās vieta ir pārredzamāka. Visvairāk neapmierinoÅ”ais ir Å”is ierobežojums:

Skatā jāatsaucas tikai uz bāzes tabulām, kas atrodas tajā paŔā datu bāzē kā skats. Skats nevar atsaukties uz citiem skatiem.

MÅ«su terminoloÄ£ijā tas nozÄ«mē, ka funkcija nevar piekļūt citai materializētai funkcijai. Tas samazina visu ideoloÄ£iju jau paŔā sākumā.
Turklāt Å”is ierobežojums (un tālāk tekstā) ievērojami samazina lietoÅ”anas gadÄ«jumu skaitu:

Skata definÄ«cijas priekÅ”raksts SELECT nedrÄ«kst saturēt Ŕādus Transact-SQL elementus:

COUNT
ROWSET funkcijas (OPENDATASOURCE, OPENQUERY, OPENROWSET, UN OPENXML)
OUTER pievienojas (LEFT, RIGHT, vai FULL)

Atvasināta tabula (definēta, norādot a SELECT paziņojums FROM klauzula)
PaŔapvienojas
Kolonnu norādīŔana, izmantojot SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, vai AVG
Kopējā tabulas izteiksme (CTE)

peldēt1, teksts, ntext, attēls, XML, vai failu straume kolonnas
ApakŔvaicājums
OVER klauzula, kas ietver ranžēŔanas vai apkopojuma loga funkcijas

Pilna teksta predikāti (CONTAINS, FREETEXT)
SUM funkcija, kas atsaucas uz nullējamu izteiksmi
ORDER BY

CLR lietotāja definēta apkopoÅ”anas funkcija
TOP
CUBE, ROLLUP, vai GROUPING SETS Uzņēmējiem

MIN, MAX
UNION, EXCEPT, vai INTERSECT Uzņēmējiem
TABLESAMPLE

Tabulas mainīgie
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Reti kolonnu komplekti
Iekļautās (TVF) vai vairāku priekÅ”rakstu tabulas vērtÄ«bas funkcijas (MSTVF)
OFFSET

CHECKSUM_AGG

ĀRĒJIE PIEVIENOJUMI, SAVIENÄŖBA, PASÅŖTÄŖJUMS un citi ir aizliegti. Varētu bÅ«t vieglāk norādÄ«t, ko varētu izmantot, nevis to, ko nevar izmantot. Saraksts, iespējams, bÅ«tu daudz Ä«sāks.

Rezumējot: milzÄ«gs ierobežojumu kopums katrā (atzÄ«mēsim komerciālo) DBVS salÄ«dzinājumā ar nevienu (izņemot vienu loÄ£isku, nevis tehnisku) LGPL tehnoloÄ£ijā. Tomēr jāatzÄ«mē, ka Ŕī mehānisma ievieÅ”ana relāciju loÄ£ikā ir nedaudz grÅ«tāka nekā aprakstÄ«tajā funkcionālajā loÄ£ikā.

IevieŔana

Kā tas strādā? PostgreSQL tiek izmantots kā ā€œvirtuālā maŔīnaā€. IekÅ”pusē ir sarežģīts algoritms, kas veido vaicājumus. Å eit avots. Un ir ne tikai liels heiristikas kopums ar virkni ifs. Tātad, ja jums ir pāris mēneÅ”i, lai studētu, jÅ«s varat mēģināt saprast arhitektÅ«ru.

Vai tas darbojas efektÄ«vi? Diezgan efektÄ«va. Diemžēl to ir grÅ«ti pierādÄ«t. Varu tikai teikt, ka, ja ņem vērā tÅ«kstoÅ”iem vaicājumu, kas pastāv lielajās lietojumprogrammās, tad vidēji tie ir efektÄ«vāki nekā laba izstrādātāja vaicājumi. Izcils SQL programmētājs var efektÄ«vāk uzrakstÄ«t jebkuru vaicājumu, bet ar tÅ«kstoÅ” vaicājumiem viņam vienkārÅ”i nebÅ«s ne motivācijas, ne laika to darÄ«t. VienÄ«gais, ko tagad varu minēt kā efektivitātes pierādÄ«jumu, ir tas, ka uz Ŕīs DBVS balstÄ«tās platformas darbojas vairāki projekti. ERP sistēmas, kurām ir tÅ«kstoÅ”iem dažādu MATERIALIZĒTU funkciju, ar tÅ«kstoÅ”iem lietotāju un terabaitu datubāzēm ar simtiem miljonu ierakstu, kas darbojas parastā divu procesoru serverÄ«. Tomēr ikviens var pārbaudÄ«t/atspēkot efektivitāti, lejupielādējot platforma un PostgreSQL, ieslēgts reÄ£istrēt SQL vaicājumus un mēģināt mainÄ«t tur esoÅ”o loÄ£iku un datus.

Nākamajos rakstos es runāŔu arÄ« par to, kā varat iestatÄ«t funkciju ierobežojumus, strādāt ar izmaiņu sesijām un daudz ko citu.

Avots: www.habr.com

Pievieno komentāru