Jafnvægi skrifar og les í gagnagrunni

Í fyrri grein Ég lýsti hugmyndinni og útfærslu gagnagrunns sem byggður er á grundvelli aðgerða, frekar en töflur og sviða eins og í venslagagnagrunnum. Það gaf mörg dæmi sem sýndu kosti þessarar aðferðar fram yfir klassísku. Mörgum fannst þær ekki nógu sannfærandi.

Í þessari grein mun ég sýna hvernig þetta hugtak gerir þér kleift að halda jafnvægi á skrifum og lestum í gagnagrunninn á fljótlegan og þægilegan hátt án þess að breyta rekstrarrökfræðinni. Svipaða virkni hefur verið reynt að innleiða í nútíma viðskiptalegum DBMS (sérstaklega Oracle og Microsoft SQL Server). Í lok greinarinnar mun ég sýna að það sem þeir gerðu, vægast sagt, heppnaðist ekki mjög vel.

Lýsing

Eins og áður, til að skilja betur mun ég byrja lýsinguna á dæmum. Segjum að við þurfum að innleiða rökfræði sem skilar lista yfir deildir með fjölda starfsmanna í þeim og heildarlaunum þeirra.

Í virkum gagnagrunni myndi það líta svona út:

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


Flækjustigið við að framkvæma þessa fyrirspurn í hvaða DBMS sem er mun jafngilda O(fjöldi starfsmanna)vegna þess að þessi útreikningur krefst þess að skanna alla töfluna yfir starfsmenn og flokka þá síðan eftir deildum. Það verður líka smá (við teljum að það séu miklu fleiri starfsmenn en deildir) viðbót eftir því hvaða áætlun er valin O(skrá fjöldi starfsmanna) eða O(fjöldi deilda) fyrir flokkun og svo framvegis.

Það er ljóst að framkvæmdarkostnaður getur verið mismunandi í mismunandi DBMS, en flækjustigið mun ekki breytast á nokkurn hátt.

Í fyrirhugaðri útfærslu mun hagnýtur DBMS búa til eina undirfyrirspurn sem mun reikna út nauðsynleg gildi fyrir deildina og gera síðan JOIN við deildartöfluna til að fá nafnið. Hins vegar, fyrir hverja aðgerð, þegar lýst er yfir, er hægt að stilla sérstakt MATERIALIZED merki. Kerfið mun sjálfkrafa búa til samsvarandi reit fyrir hverja slíka aðgerð. Þegar gildi falls er breytt mun gildi reitsins einnig breytast í sömu færslu. Þegar þessi aðgerð er opnuð verður aðgangur að forútreiknaða reitnum.

Sérstaklega ef þú stillir MATERIALIZED fyrir aðgerðir telja starfsmenn и launSumma, þá bætast tveir reitir við töfluna með lista yfir deildir, sem geymir fjölda starfsmanna og heildarlaun þeirra. Alltaf þegar breytingar verða á starfsmönnum, launum þeirra eða deildatengslum mun kerfið sjálfkrafa breyta gildum þessara reita. Ofangreind fyrirspurn mun fá aðgang að þessum reitum beint og verður keyrð í O(fjöldi deilda).

Hverjar eru takmarkanirnar? Aðeins eitt: slík aðgerð verður að hafa takmarkaðan fjölda inntaksgilda sem gildi hennar er skilgreint fyrir. Annars verður ómögulegt að búa til töflu sem geymir öll gildi hennar, þar sem það getur ekki verið tafla með óendanlega mörgum línum.

Dæmi:

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


Þessi aðgerð er skilgreind fyrir óendanlega fjölda gilda af N (til dæmis hentar hvaða neikvætt gildi sem er). Þess vegna geturðu ekki sett MATERIALIZED á það. Þannig að þetta er rökrétt takmörkun, ekki tæknileg (það er ekki vegna þess að við gátum ekki innleitt hana). Annars eru engar takmarkanir. Hægt er að nota flokkanir, flokkun, OG og EÐA, SKILNING, endurviku o.s.frv.

Til dæmis, í dæmi 2.2 í fyrri grein, geturðu sett MATERIALIZED á báðar aðgerðir:

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;


Kerfið sjálft mun búa til eina töflu með tegund lykla Viðskiptavinur, vara и HEILT, mun bæta tveimur reitum við það og mun uppfæra svæðisgildin í þeim með öllum breytingum. Þegar frekari símtöl í þessar aðgerðir eru gerðar verða þær ekki reiknaðar, heldur verða gildin lesin úr samsvarandi reitum.

Með því að nota þetta kerfi geturðu til dæmis losað þig við endurtekningar (CTE) í fyrirspurnum. Sérstaklega skaltu íhuga hópa sem mynda tré með því að nota barn/foreldri sambandið (hver hópur hefur tengil á foreldri sitt):

parent = DATA Group (Group);


Í virkum gagnagrunni er hægt að tilgreina endurtekningarrökfræði sem hér segir:

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;


Síðan fyrir aðgerðina er Foreldri er merkt MATERIALIZED, þá verður til tafla með tveimur lyklum (hópum) fyrir hana, þar sem reiturinn er Foreldri verður aðeins satt ef fyrsti lykillinn er barn hins seinni. Fjöldi færslna í þessari töflu mun vera jöfn fjölda hópa margfaldað með meðaldýpt trésins. Ef þú þarft til dæmis að telja fjölda afkomenda ákveðins hóps geturðu notað þessa aðgerð:

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


Það verður engin CTE í SQL fyrirspurninni. Í staðinn verður einfaldur GROUP BY.

Með því að nota þetta kerfi geturðu einnig auðveldlega afeðlað gagnagrunninn ef þörf krefur:

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

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


Þegar hringt er í aðgerð dagsetning fyrir pöntunarlínuna verður reiturinn sem vísitala er fyrir lesinn úr töflunni með pöntunarlínum. Þegar pöntunardagsetningin breytist mun kerfið sjálft sjálfkrafa endurreikna óeðlilega dagsetninguna í línunni.

Kostir

Til hvers er þetta kerfi allt? Í klassískum DBMS, án þess að endurskrifa fyrirspurnir, getur verktaki eða DBA aðeins breytt vísitölum, ákvarðað tölfræði og sagt fyrirspurnaskipuleggjandinum hvernig á að framkvæma þær (og vísbendingar eru aðeins fáanlegar í viðskiptalegum DBMS). Sama hversu mikið þeir reyna, þeir munu ekki geta lokið fyrstu fyrirspurninni í greininni í O (fjöldi deilda) án þess að breyta fyrirspurnum eða bæta við kveikjum. Í fyrirhuguðu kerfi, á þróunarstigi þarftu ekki að hugsa um uppbyggingu gagnageymslunnar og hvaða samsöfnun á að nota. Allt þetta er auðvelt að breyta á flugu, beint í notkun.

Í reynd lítur þetta svona út. Sumt fólk þróar rökfræði beint út frá verkefninu sem fyrir hendi er. Þeir skilja ekki reiknirit og flókið þeirra, né framkvæmdaráætlanir, né tegundir samskeytis, né neinn annan tæknilegan þátt. Þetta fólk er meira viðskiptafræðingar en verktaki. Síðan fer allt þetta í prófun eða rekstur. Gerir kleift að skrá langvarandi fyrirspurnir. Þegar löng fyrirspurn greinist, þá ákveður annað fólk (tæknilegra - eiginlega DBA) að virkja MATERIALIZED á einhverri milliaðgerð. Þetta hægir aðeins á upptökunni (þar sem það krefst uppfærslu á viðbótarreit í viðskiptunum). Hins vegar er ekki aðeins þessari fyrirspurn hraðað verulega, heldur einnig öllum öðrum sem nota þessa aðgerð. Á sama tíma er tiltölulega auðvelt að ákveða hvaða aðgerð eigi að veruleika. Tvær aðalfæribreytur: fjöldi mögulegra inntaksgilda (þetta er hversu margar færslur verða í samsvarandi töflu) og hversu oft það er notað í öðrum aðgerðum.

Analogs

Nútíma DBMS í auglýsingum hafa svipaða aðferðir: MATERIALIZED VIEW með FAST REFRESH (Oracle) og INDEXED VIEW (Microsoft SQL Server). Í PostgreSQL er ekki hægt að uppfæra MATERIALIZED VIEW í viðskiptum, heldur aðeins að beiðni (og jafnvel með mjög ströngum takmörkunum), svo við teljum það ekki. En þeir hafa nokkur vandamál sem takmarka verulega notkun þeirra.

Í fyrsta lagi geturðu aðeins virkjað efnisgerð ef þú hefur þegar búið til venjulega VIEW. Annars verður þú að endurskrifa þær beiðnir sem eftir eru til að fá aðgang að nýstofnuðu útsýninu til að nota þessa efnisgerð. Eða láttu allt vera eins og það er, en það mun að minnsta kosti vera árangurslaust ef það eru ákveðin fyrirfram útreiknuð gögn, en margar fyrirspurnir nota þau ekki alltaf, heldur endurreikna þau.

Í öðru lagi hafa þeir gríðarlegan fjölda takmarkana:

Oracle

5.3.8.4 Almennar takmarkanir á hraðuppfærslu

Skilgreiningarfyrirspurn hins efnislega yfirlits er takmörkuð sem hér segir:

• Hin efnislega sýn má ekki innihalda tilvísanir í orðasambönd sem ekki eru endurtekin eins og SYSDATE og ROWNUM.
• Veruleikasýn má ekki innihalda tilvísanir í RAW or LONG RAW gagnategundir.
• Það getur ekki innihaldið a SELECT lista undirfyrirspurn.
• Það getur ekki innihaldið greiningaraðgerðir (td RANK) í SELECT ákvæði.
• Það getur ekki vísað til töflu þar sem an XMLIndex vísitala er skilgreind.
• Það getur ekki innihaldið a MODEL ákvæði.
• Það getur ekki innihaldið a HAVING ákvæði með undirfyrirspurn.
• Það getur ekki innihaldið innbyggðar fyrirspurnir sem hafa ANY, ALL, eða NOT EXISTS.
• Það getur ekki innihaldið a [START WITH …] CONNECT BY ákvæði.
• Það getur ekki innihaldið margar smáatriði töflur á mismunandi stöðum.
• ON COMMIT efnislegar skoðanir geta ekki haft fjarskiptatöflur.
• Hreiður efnisleg skoðanir verða að hafa sameiningu eða samansafn.
• Verulega sameinuð skoðanir og efnislegar samanlagðar skoðanir með a GROUP BY ákvæði getur ekki valið úr vísitöluskipulagðri töflu.

5.3.8.5 Takmarkanir á hraðuppfærslu á efnisbundnum áhorfum eingöngu með sameiningu

Að skilgreina fyrirspurnir fyrir efnislegar skoðanir með sameiningum eingöngu og engum uppsöfnun hefur eftirfarandi takmarkanir á hraðuppfærslu:

• Allar takmarkanir frá «Almennar takmarkanir á hraðuppfærslu".
• Þeir geta ekki haft GROUP BY ákvæðum eða samantektum.
• Rowids af öllum borðum í FROM listi verður að birtast í SELECT lista yfir fyrirspurnina.
• Efnisbundnar skoðanaskrár verða að vera til með röðum fyrir allar grunntöflurnar í FROM lista yfir fyrirspurnina.
• Þú getur ekki búið til hratt endurnýjanlega efnislega mynd úr mörgum töflum með einföldum samskeytum sem innihalda hlutgerðardálk í SELECT yfirlýsing.

Einnig mun endurnýjunaraðferðin sem þú velur ekki vera best skilvirk ef:

• Skilgreiningarfyrirspurnin notar ytri tengingu sem hegðar sér eins og innri tenging. Ef skilgreiningarfyrirspurnin inniheldur slíka tengingu skaltu íhuga að endurskrifa skilgreiningarfyrirspurnina til að innihalda innri tengingu.
• The SELECT listi yfir efnisyfirlitið inniheldur tjáningar á dálkum úr mörgum töflum.

5.3.8.6 Takmarkanir á hraðuppfærslu á efnisbundnu áhorfi með samantektum

Að skilgreina fyrirspurnir fyrir efnislegar skoðanir með uppsöfnun eða sameiningu hefur eftirfarandi takmarkanir á hraðuppfærslu:

• Allar takmarkanir frá «Almennar takmarkanir á hraðuppfærslu".

Hraðuppfærsla er studd fyrir bæði ON COMMIT og ON DEMAND að veruleika skoðana, þó gilda eftirfarandi takmarkanir:

• Allar töflur í efnisyfirlitinu verða að hafa efnisskráða yfirlitsskrá og efnisskráðir yfirlitsskrár verða:
  • Inniheldur alla dálka úr töflunni sem vísað er til í efnisyfirlitinu.
  • Tilgreindu með ROWID og INCLUDING NEW VALUES.
  • tilgreina SEQUENCE ákvæði ef ætlast er til að taflan hafi blöndu af innskotum/beinni hleðslu, eyðingu og uppfærslum.

• Aðeins SUM, COUNT, AVG, STDDEV, VARIANCE, MIN og MAX eru studd fyrir hraðuppfærslu.
• COUNT(*) verður að tilgreina.
• Samanlögð föll verða aðeins að koma fram sem ysti hluti tjáningarinnar. Það er að segja safnefni eins og AVG(AVG(x)) or AVG(x)+ AVG(x) eru ekki leyfðar.
• Fyrir hverja heild eins og AVG(expr), samsvarandi COUNT(expr) verður að vera til staðar. Oracle mælir með því SUM(expr) vera tilgreindur.
• If VARIANCE(expr) or STDDEV(expr) er tilgreint, COUNT(expr) og SUM(expr) verður að tilgreina. Oracle mælir með því SUM(expr *expr) vera tilgreindur.
• The SELECT dálkur í skilgreiningarfyrirspurninni getur ekki verið flókin tjáning með dálkum úr mörgum grunntöflum. Möguleg lausn á þessu er að nota hreiðrað efnislegt útsýni.
• The SELECT listi verður að innihalda allt GROUP BY dálkar.
• Hin efnislega sýn er ekki byggð á einni eða fleiri ytri töflum.
• Ef þú notar a CHAR gagnategund í síudálkum efnisbundins útsýnisskrár, stafasett af aðalsíðunni og efnisvalmyndinni verða að vera þau sömu.
• Ef efnisyfirlitið hefur eitt af eftirfarandi, þá er hraðuppfærsla aðeins studd á hefðbundnum DML innskotum og beinni hleðslu.
  • Veruleikaviðhorf með MIN or MAX samanlagður
  • Veruleikaviðhorf sem hafa SUM(expr) en nei COUNT(expr)
  • Veruleika skoðanir án COUNT(*)

  Slík efnisgerð skoðun er kölluð efnisbundin skoðun sem eingöngu er sett inn.

• Veruleikasýn með MAX or MIN er hratt endurnýjanlegt eftir eyðingu eða blandaðar DML-yfirlýsingar ef það er ekki með a WHERE ákvæði.
  Hámarks/mín hraðhresslan eftir eyðingu eða blandað DML hefur ekki sömu hegðun og innskotsfallið. Það eyðir og endurreikur hámarks/mín gildin fyrir viðkomandi hópa. Þú þarft að vera meðvitaður um áhrif þess á frammistöðu.
• Efnislegar skoðanir með nafngreindum skoðunum eða undirfyrirspurnum í FROM ákvæði er hægt að endurnýja fljótt að því tilskildu að hægt sé að sameina sjónarmiðin alveg. Fyrir upplýsingar um hvaða skoðanir munu sameinast, sjá Oracle Database SQL tungumálavísun.
• Ef það eru engar ytri tengingar gætirðu haft handahófskenndar val og tengingar í WHERE ákvæði.
• Efnislegar heildarmyndir með ytri samskeytum eru fljótlegar endurnýjanlegar eftir hefðbundna DML og beina álag, að því tilskildu að aðeins ytri töflunni hafi verið breytt. Einnig verða einstakar takmarkanir að vera fyrir sameiningardálka innri sameiningartöflunnar. Ef það eru ytri tengingar verða allar tengingar að vera tengdar með ANDs og verður að nota jafnrétti (=) rekstraraðili.
• Fyrir efnislegar skoðanir með CUBE, ROLLUP, flokkunarsett eða samtenging þeirra, gilda eftirfarandi takmarkanir:
  • The SELECT listi ætti að innihalda flokkunargrein sem getur annað hvort verið a GROUPING_ID virka á öllum GROUP BY tjáning eða GROUPING virkar eitt fyrir hvern GROUP BY tjáningu. Til dæmis, ef GROUP BY ákvæði hinnar raunhæfu skoðunar er "GROUP BY CUBE(a, b)", þá SELECT listi ætti að innihalda annað hvort "GROUPING_ID(a, b)» eða «GROUPING(a) AND GROUPING(b)» til að hið raunverulega útsýni sé hratt endurnýjanlegt.
  • GROUP BY ætti ekki að leiða til tvítekinna hópa. Til dæmis, "GROUP BY a, ROLLUP(a, b)" er ekki hægt að endurnýja hratt vegna þess að það leiðir til tvítekinna hópa "(a), (a, b), AND (a)".

5.3.8.7 Takmarkanir á hraðuppfærslu á efnisbundnu útsýni með UNION ALL

Veruleika skoðanir með UNION ALL stilla rekstraraðila styðja REFRESH FAST valmöguleika ef eftirfarandi skilyrði eru uppfyllt:

• Skilgreiningarfyrirspurnin verður að hafa UNION ALL rekstraraðili á efsta stigi.

  The UNION ALL Ekki er hægt að fella stjórnanda inn í undirfyrirspurn, með einni undantekningu: The UNION ALL getur verið í undirfyrirspurn í FROM ákvæði að því tilskildu að skilgreiningarfyrirspurnin sé í formi SELECT * FROM (skoða eða undirfyrirspurn með UNION ALL) eins og í eftirfarandi dæmi:

  CREATE VIEW view_with_unionall AS (SELECT c.rowid crid, c.cust_id, 2 umarker FROM viðskiptavinum c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker FRÁ viðskiptavinum c WHERE c.cust_last_name = 'Jones'); Búðu til efnisbundið ÚTSÝNING unionall_inside_view_mv UPPFÆRSLA HRATT EFTIR EFTIR EFTIR EFTIR EFTIR VALIÐ * FROM view_with_unionall;
  

  Athugið að útsýnið view_with_unionall uppfyllir kröfur um hraðuppfærslu.

• Hver fyrirspurnarblokk í UNION ALL fyrirspurn verður að fullnægja kröfum um hraðendurnýjanlegt efnislegt útsýni með samanlagðri mynd eða hraðendurnýjanlegt efnislegt útsýni með samskeyti.

  Viðeigandi efnisskrárskrár verða að vera búnar til á töflunum eins og krafist er fyrir samsvarandi tegund af hröðum endurnýjunarmyndum.
  Athugaðu að Oracle gagnagrunnurinn leyfir einnig sérstakt tilfelli af einni töflu að veruleika útsýni með sameiningum aðeins að því gefnu ROWID dálkurinn hefur verið innifalinn í SELECT lista og í efnisskráðri skoðunarskrá. Þetta er sýnt í skilgreiningarfyrirspurn yfirlitsins view_with_unionall.

• The SELECT listi yfir hverja fyrirspurn verður að innihalda a UNION ALL merki, og UNION ALL dálkurinn verður að hafa sérstakt stöðugt tölugildi eða strengjagildi í hverjum UNION ALL útibú. Ennfremur verður merkisdálkurinn að birtast í sömu raðstöðu í SELECT lista yfir hvern fyrirspurnareit. Sjá "UNION ALL Marker og Query Rewrite» fyrir frekari upplýsingar um UNION ALL merkimiðar.
• Sumir eiginleikar eins og ytri tengingar, innskotsuppsöfnuð útlitsfyrirspurnir og ytri töflur eru ekki studdar fyrir efnislegar skoðanir með UNION ALL. Athugaðu hins vegar að hægt er að endurnýja efnislegar skoðanir sem notaðar eru í afritun, sem innihalda ekki samskeyti eða samsöfnun, þegar UNION ALL eða fjarlæg borð eru notuð.
• Samhæfi frumstillingarfæribreytan verður að vera stillt á 9.2.0 eða hærra til að búa til hratt endurnýjanlega efnislega mynd með UNION ALL.

Ég vil ekki móðga Oracle aðdáendur, en miðað við lista yfir takmarkanir þeirra virðist sem þetta kerfi hafi ekki verið skrifað í almennu tilviki, með einhvers konar fyrirmynd, heldur af þúsundum Indverja, þar sem öllum var gefinn kostur á að skrifaðu sína grein og hver þeirra gerði það sem hann gat og gerði. Að nota þetta kerfi fyrir alvöru rökfræði er eins og að ganga í gegnum jarðsprengjusvæði. Þú getur fengið námu hvenær sem er með því að fara á eina af óljósu takmörkunum. Hvernig það virkar er líka sérstök spurning, en það er utan gildissviðs þessarar greinar.

Microsoft SQLServer

Viðbótarkröfur

Til viðbótar við SET valkostina og kröfur um ákvarðanavirkni, verður að uppfylla eftirfarandi kröfur:

• Notandinn sem keyrir CREATE INDEX verður að vera eigandi útsýnisins.
• Þegar þú býrð til vísitöluna, er IGNORE_DUP_KEY valkosturinn verður að vera stilltur á OFF (sjálfgefin stilling).
• Töflur verða að vera tilvísaðar með tvíþættum nöfnum, stefið.borðnafn í útsýnisskilgreiningunni.
• Notendaskilgreindar aðgerðir sem vísað er til í yfirlitinu verður að búa til með því að nota WITH SCHEMABINDING valkostur.
• Allar notendaskilgreindar aðgerðir sem vísað er til í yfirlitinu verður að vera vísað til með tveggja hluta nöfnum, ..
• Gagnaaðgangseiginleiki notendaskilgreindrar falls verður að vera NO SQL, og ytri aðgangseign verður að vera NO.
• Common Language Runtime (CLR) aðgerðir geta birst í vallista yfirlitsins, en geta ekki verið hluti af skilgreiningu á þyrpta vísitölulyklinum. CLR aðgerðir geta ekki birst í WHERE-ákvæðinu í yfirlitinu eða ON-ákvæðinu í JOIN-aðgerð í yfirlitinu.
• CLR aðgerðir og aðferðir CLR notendaskilgreindra tegunda sem notaðar eru í útsýnisskilgreiningunni verða að hafa eiginleikana stillta eins og sýnt er í eftirfarandi töflu.

  Property
  Athugaðu

  DETERMINISTIC = SATT
  Verður að vera skýrt tilgreind sem eiginleiki Microsoft .NET Framework aðferðarinnar.

  NÁKVÆMT = SATT
  Verður að vera skýrt tilgreind sem eiginleiki .NET Framework aðferðarinnar.

  DATA ACCESS = ENGINN SQL
  Ákvörðuð með því að stilla DataAccess eigind á DataAccessKind.None og SystemDataAccess eigind á SystemDataAccessKind.None.

  YTARI AÐGANGUR = NEI
  Þessi eiginleiki er sjálfgefið NEI fyrir CLR venjur.

• Útsýnið verður að búa til með því að nota WITH SCHEMABINDING valkostur.
• Yfirlitið verður aðeins að vísa til grunntöflur sem eru í sama gagnagrunni og útsýnið. Útlitið getur ekki vísað til annarra skoðana.
• SELECT setningin í útsýnisskilgreiningunni má ekki innihalda eftirfarandi Transact-SQL þætti:

  COUNT
  ROWSET aðgerðir (OPENDATASOURCE, OPENQUERY, OPENROWSET, OG OPENXML)
  OUTER tengist (LEFT, RIGHT, eða FULL)

  Afleidd tafla (skilgreind með því að tilgreina a SELECT yfirlýsingu í FROM ákvæði)
  Gengur sjálf
  Tilgreina dálka með því að nota SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARP, eða AVG
  Common table expression (CTE)

  fljóta1, texta, ntexti, mynd, XML, eða skráarstraumur dálkar
  Subquery
  OVER ákvæði, sem inniheldur röðun eða uppsafnaða gluggaaðgerðir

  Forsaga í fullri texta (CONTAINS, FREETEXT)
  SUM fall sem vísar til núllhæfrar tjáningar
  ORDER BY

  CLR notendaskilgreint heildarfall
  TOP
CUBE, ROLLUP, eða GROUPING SETS rekstraraðilar

  MIN, MAX
UNION, EXCEPT, eða INTERSECT rekstraraðilar
  TABLESAMPLE

  Taflabreytur
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  Dreifð súlusett
  Innbyggð (TVF) eða multi-statement table-valued functions (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 Verðtryggða yfirlitið getur innihaldið fljóta súlur; þó er ekki hægt að taka slíka dálka með í þyrpingavísitölulyklinum.

• If GROUP BY er til staðar verður VIEW skilgreiningin að innihalda COUNT_BIG(*) og má ekki innihalda HAVING. Þetta GROUP BY takmarkanir eiga aðeins við um skilgreiningu verðtryggðrar skoðana. Fyrirspurn getur notað verðtryggða sýn í framkvæmdaráætlun sinni jafnvel þó hún uppfylli ekki þær GROUP BY takmarkanir.
• Ef útsýnisskilgreiningin inniheldur a GROUP BY ákvæði, lykillinn að einstöku þyrpingavísitölunni getur aðeins vísað til dálka sem tilgreindir eru í GROUP BY ákvæði.

Það er ljóst hér að Indverjar komu ekki við sögu, þar sem þeir ákváðu að gera það samkvæmt áætluninni „við munum gera lítið, en vel. Það er að segja að þeir eru með fleiri námur á vellinum en staðsetning þeirra er gagnsærri. Það sem veldur mestum vonbrigðum er þessi takmörkun:

Yfirlitið verður aðeins að vísa til grunntöflur sem eru í sama gagnagrunni og útsýnið. Útlitið getur ekki vísað til annarra skoðana.

Í hugtökum okkar þýðir þetta að aðgerð hefur ekki aðgang að annarri efnislegri aðgerð. Þetta sker niður alla hugmyndafræði í buddunni.
Einnig dregur þessi takmörkun (og lengra í textanum) verulega úr notkunartilvikum:

SELECT setningin í útsýnisskilgreiningunni má ekki innihalda eftirfarandi Transact-SQL þætti:

COUNT
ROWSET aðgerðir (OPENDATASOURCE, OPENQUERY, OPENROWSET, OG OPENXML)
OUTER tengist (LEFT, RIGHT, eða FULL)

Afleidd tafla (skilgreind með því að tilgreina a SELECT yfirlýsingu í FROM ákvæði)
Gengur sjálf
Tilgreina dálka með því að nota SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, eða AVG
Common table expression (CTE)

fljóta1, texta, ntexti, mynd, XML, eða skráarstraumur dálkar
Subquery
OVER ákvæði, sem inniheldur röðun eða uppsafnaða gluggaaðgerðir

Forsaga í fullri texta (CONTAINS, FREETEXT)
SUM fall sem vísar til núllhæfrar tjáningar
ORDER BY

CLR notendaskilgreint heildarfall
TOP
CUBE, ROLLUP, eða GROUPING SETS rekstraraðilar

MIN, MAX
UNION, EXCEPT, eða INTERSECT rekstraraðilar
TABLESAMPLE

Taflabreytur
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Dreifð súlusett
Innbyggð (TVF) eða multi-statement table-valued functions (MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOINS, UNION, ORDER BY og aðrir eru bönnuð. Það hefði kannski verið auðveldara að tilgreina hvað væri hægt að nota frekar en hvað væri ekki hægt að nota. Listinn væri líklega mun minni.

Til að draga saman: gríðarstórt sett af takmörkunum í öllum (tökum eftir auglýsingum) DBMS á móti engum (að undanskildum einum rökréttum, ekki tæknilegum) í LGPL tækni. Hins vegar skal tekið fram að innleiðing þessa kerfis í venslarökfræði er nokkuð erfiðari en í virknirökfræðinni sem lýst er.

Framkvæmd

Hvernig það virkar? PostgreSQL er notað sem „sýndarvél“. Það er flókið reiknirit inni sem býr til fyrirspurnir. Hérna heimild. Og það er ekki bara mikið sett af heuristics með fullt af ef. Svo ef þú hefur nokkra mánuði til að læra geturðu reynt að skilja arkitektúr.

Virkar það á áhrifaríkan hátt? Alveg áhrifaríkt. Því miður er erfitt að sanna þetta. Ég get aðeins sagt að ef þú lítur á þúsundir fyrirspurna sem eru til í stórum forritum, þá eru þær að meðaltali skilvirkari en góðs þróunaraðila. Framúrskarandi SQL forritari getur skrifað hvaða fyrirspurn sem er á skilvirkari hátt, en með þúsund fyrirspurnum mun hann einfaldlega ekki hafa hvatningu eða tíma til að gera það. Það eina sem ég get nú nefnt sem sönnun um skilvirkni er að nokkur verkefni eru að vinna á pallinum sem byggður er á þessu DBMS ERP kerfi, sem hafa þúsundir mismunandi MATERIALIZED aðgerðir, með þúsundum notenda og terabæta gagnagrunna með hundruð milljóna skráa sem keyra á venjulegum tveggja örgjörva netþjóni. Hins vegar getur hver sem er athugað/hafna virknina með því að hlaða niður pallur og PostgreSQL, kveikt á skráir SQL fyrirspurnir og reyna að breyta rökfræði og gögnum þar.

Í eftirfarandi greinum mun ég einnig tala um hvernig þú getur sett takmarkanir á aðgerðir, unnið með breytingarlotur og margt fleira.

Heimild: www.habr.com