Andmete lugemise ja kirjutamise tasakaalustamine andmebaasis

Eelmises osas artiklis Olen kirjeldanud andmebaasi kontseptsiooni ja rakendust, mis põhinevad funktsioonidel, mitte tabelitel ja väljadest nagu suheline andmebaas. Toodud on palju näiteid, mis demonstreerivad sellise lähenemise eeliseid klassikalise ees. Paljud pidasid neid piisavalt veenvateks.

Selles artiklis näitan, kuidas selline kontseptsioon võimaldab kiiresti ja mugavalt tasakaalustada andmebaasi kirjutamist ja lugemist ilma igasuguste muudatusteta töölogikas. Sarnast funktsionaalsust on püüdnud rakendada tänapäevased kaubanduslikud andmebaasisüsteemid (eriti Oracle ja Microsoft SQL Server). Artikli lõpus näitan, kuidas neil see õnnestus, õrnalt öeldes, mitte eriti hästi.

Kirjeldus

Nagu eelnevalt, parima arusaamise jaoks alustan kirjeldust näidetega. Oletame, et peame rakendama loogikat, mis tagastab osakondade nimekirja nende töötajate arvu ja kogupalkadega.

Funktsionaalses andmebaasis näeks see välja järgmiselt:

CLASS Department ‘Osakond’;
name ‘Nimi’ = DATA STRING[100] (Osakond);

CLASS Employee 'Töötaja';
department 'Osakond' = DATA Department (Employee);
salary 'Palk' = DATA NUMERIC[10,2] (Employee);

countEmployees 'Töötajate arv' (Department d) = 
    GRUPP SUM 1 KUI osakond (Töötaja e) = d;
palgaSum 'Kogupalga' (Osakond d) = 
    GRUPP SUM palk (Töötaja e) KUI osakond (e) = d;

VALI nimi (Osakond d), töötajate arv (d), palgaSum (d);

Selle päringu täitmise keerukus igas andmebaasis on ekvivalentne O(töötajate arv), kuna selle arvutamise jaoks tuleb skaneerida kogu töötajate tabelit ning seejärel rühmitada nad osakondade kaupa. Samuti tuleb arvesse võtta natuke (arvestame, et töötajaid on palju rohkem kui osakondi) lisa sõltuvalt valitud plaanist O(log töötajate arv) või O(osakondade arv) rühmitamise ja muude tegevuste jaoks.

On selge, et täitmise ülejäänud kulud võivad erinevates andmebaasides olla erinevad, kuid keerukus ei muutu kuidagi.

Pakutud rakenduses loob funktsionaalne andmebaasisüsteem ühe alamküsimuse, mis arvutab osakonna jaoks vajalikud väärtused ja seejärel teeb JOIN osakondade tabeliga, et saada nime. Siiski, iga funktsiooni deklareerimise ajal on võimalik määrata eriline märkeruum MATERIALIZED. Süsteem loob automaatselt vastava välja iga sellise funktsiooni jaoks. Funktsiooni väärtuse muutmisel muudetakse selle välja väärtust samas tehingus. Funktsiooni kõnetamisel toimib see juba eelnevalt arvutatud välja põhjal.

Konkreetsete funktsioonide puhul, kui määrata MATERIALIZED countEmployees ja salarySum, lisatakse osakondade nimekirja tabelisse kaks välja, kus hoitakse töötajate arvu ja nende kogupalka. Ükskõik millise töötaja, nende palga või osakondade kuuluvuse muutumise korral muudab süsteem nende välja väärtusi automaatselt. Eelpool toodud päring hakkab otseselt nende väljade poole pöörduma ja täidetakse kiiremini. O(osakondade arv).

Millised on piirangud? Ainult üks: selle funktsiooni jaoks peab olema piiratud hulk sisendväärtusi, mille jaoks selle väärtus on määratud. Muidu ei saa ehitada tabelit, mis salvestab kõik selle väärtused, kuna ei saa olla tabelit, millel on lõpmatu arv ridasid.

Näide:

employeesCount 'Töötajate arv, kelle palk on > N' (Osakond d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;


See funktsioon on määratud lõpmatu arvu N väärtuste jaoks (näiteks sobib mis tahes negatiivne väärtus). Seetõttu ei saa sellele määrata MATERIALIZED. Seega on see loogiline, mitte tehniline piirang (see ei ole tingitud sellest, et me ei suutnud seda rakendada). Muus osas — mingeid piiranguid pole. Võib kasutada rühmitamisi, sorteerimisi, AND ja OR, PARTITION, rekurssioone jne.

Näiteks ülesandes 2.2 eelnevas artiklis võib mõlemas funktsioonis määrata MATERIALIZED:

ostetud 'Ostetud' (Kliendid c, Toode p, KOHANE y) = 
    GRUPI SUMMA sum(Detail d) KUI 
        klient(order(d)) = c JA 
        toode(d) = p JA 
        välja võttaAasta(date(order(d))) = y MATERJALISEERITUD;
hinnang 'Hinnang' (Kliendid c, Toode p, KOHANE y) = 
    PARTITSIOONI SUMMA 1 KORD DESC ostetud(c, p, y), p RÖNDI c, y MATERJALISEERITUD;
VALI kontaktNimi(Kliendid c), nimi(Toode p) KUS hinnang(c, p, 1997) < 3;


Süsteem loob ise ühe tabeli tüübi võtmetega Klient, Toode ja INTEGER, lisab sinna kaks väljad ja uuendab nende väärtusi igasuguste muudatuste korral. Edasi liikudes ei toimu nende funktsioonide arvutamist, vaid vastavad väärtused loetakse vastavatest väljadest.

Selle mehhanismi abil on võimalik, näiteks, lahti saada rekursioonidest (CTE) päringutes. Spetsiaalselt vaatame gruppe, mis moodustavad puu child/parent suhte abil (iga grupil on link oma vanemale):

parent = DATA Group (Group);


Funktsionaalses andmebaasis saab rekursioonide loogika määrata järgmiselt:

tase (Grupi laps, Grupi vanem) = REKURSIOON 1l KUI laps ON Grupp JA vanem == laps
                                                             SAMM 2l KUI vanem == vanem($vanem);
onVanem (Grupi laps, Grupi vanem) = TÕSI KUI tase(laps, vanem) MATERJALISEERITUD;


Kuna funktsiooni isParent juures on määratud MATERIALIZED, siis selle jaoks luuakse tabel kahes võtmes (gruppides), kus väli isParent on tõene ainult siis, kui esimene võti on teise järelmanne. Selle tabeli ridade arv on võrdeliselt gruppide arvuga, korrutatuna puu keskmise sügavusega. Kui on vaja, näiteks, kindla grupi järeltulijate arvu arvestada, siis saab sellele funktsioonile viidata:

lasteArv (Grupp g) = GRUPP SUM 1 KUI on vanem (Grupp laps, g);


SQL päringus ei ole mingit CTE-d. Selle asemel on tegemist lihtsa GROUP BY-ga.

Selle mehhanismi abil saab samuti vajadusel andmebaasi denormaliseerimist hõlpsasti teostada:

CLASS Order 'Tellimus';
date 'Kuupäev' = DATA DATE (Tellimus);

CLASS OrderDetail 'Tellimuse rida';
order 'Tellimus' = DATA Order (OrderDetail);
date 'Kuupäev' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;

Funktsioonile viidates date Tellimustabeli jaoks loetakse tellimuste ridade tabelist välja väljad, millel on indeks. Kui tellimuse kuupäev muutub, arvutab süsteem automaatselt denormaliseeritud kuupäeva.

Eelised

Mis on kogu selle mehhanismi eesmärk? Klassikalistes andmebaasides, ilma päringute edasise muutmiseta, saab arendaja või andmebaasi administraator ainult indekseid muuta, statistikat määrata ning anda päringute plaanijale juhiseid, kuidas neid täita (kuid HINT'e on olemas ainult kommertstoodetes). Kui nad ei pinguta, ei suuda nad esimest päringut artiklis täita. O (osakondade arv) ilma päringute muutmiseta ja käivitustriggerite kirjutamiseta. Pakutud skeemis ei pea arendamisetapis mõtlema andmete salvestamise struktuurile ja selle peale, milliseid agregaatfunktsioone kasutada. Kõike seda saab mugavalt muuta reaalajas juba samaaegselt kasutuses.

Kä praktikas näeb see välja järgmiselt. Mõned inimesed arendavad otseselt loogikat ülesande põhjal. Nad ei tunne algoritme ega nende keerukust, ega täitmisplaane, ega join-tüüpe, ega muid tehnilisi aspekte. Need inimesed on pigem ärianalüütikud kui arendajad. Seejärel suundub kõik testimisele või käitusse. Lülitatakse sisse pikaajaliste päringute logimine. Kui avastatakse pikaajaline päring, siis otsustavad selle juba teised inimesed (tehnilisemad — sisuliselt DBA-d), et aktiveerida MATERIALIZED mõnes vahefunktsioonis. See aeglustab natuke kirjutamist (kuna nõuab täiendava välja uuendamist tehingus). Kuid see kiirendab oluliselt mitte ainult seda päringut, vaid ka kõiki teisi, mis seda funktsiooni kasutavad. Otsuse tegemine, millist funktsiooni materialiseerida, on suures osas lihtne. Kaks peamist parameetrit: võimalikud sisendväärtuste arv (täpselt nii palju kirjeid on vastavas tabelis) ja kui sageli seda kasutatakse teistes funktsioonides.

Analoogid

Kaasaegsetes kaubanduskeskkondade andmebaasi haldustoodetes on sarnased mehhanismid: MATERIALISEERITUD VAATEPILT FAST REFRESH (Oracle) ja INDEXED VIEW (Microsoft SQL Server). PostgreSQL'is ei saa MATERIALISEERITUD VAATEPILT uuendada tehingus, vaid ainult päringu kaudu (ja üsna range piirangutega), nii et seda ei käsitleta. Kuid neil on mitmeid probleeme, mis piiravad oluliselt nende kasutamist.

Esiteks, materialiseerimist saab lubada ainult siis, kui olete juba loonud tavalise VAATEPILDI. Vastasel juhul peate ümber kirjutama kõik ülejäänud päringud uue loodud vaatepildi kasutamiseks, et kasutada seda materialiseerimist. Või jätta kõik nagu on, kuid see on vähemalt ebaefektiivne, kui mõned andmed on juba ette arvutatud, aga palju päringud ei kasuta neid alati, vaid arvutavad uuesti.

Teiseks, neil on tohutu hulk piiranguid:

Oracle

5.3.8.4 Üldised piirangud kiireks värskendamiseks

Materjaliseeritud vaatepildi määratlev päring on piiratud järgmiselt:

• Materjaliseeritud vaatepilt ei tohi sisaldada viiteid kordumatutele väljenditele nagu SYSDATE ja ROWNUM.
• Materjaliseeritud vaatepilt ei tohi sisaldada viiteid RAW või LONG RAW andme tüüpidele.
• See ei tohi sisaldada SELECT loendi alampäringut.
• See ei tohi sisaldada analüütilisi funktsioone (näiteks RANK) lauses. SELECT See ei tohi viidata tabelile, millel on määratud
• XMLIndex indeks. indeksi on määratud.
• See ei tohi sisaldada MUDAL See ei tohi viidata tabelile, millel on määratud
• See ei tohi sisaldada HAVING lause koos alampäringuga.
• See ei tohi sisaldada pesaküsimusi, mis sisaldavad ANY, ALL, või NOT EXISTS.
• See ei tohi sisaldada [START WITH …] ÜHENDUS BY See ei tohi viidata tabelile, millel on määratud
• See ei saa sisaldada mitut detailtabelit erinevates kohtades.
• KAS COMMIT materjaliseeritud vaated ei saa omada kauguseid detailtabeleid.
• Sisetustatud materiaalsed vaated peavad sisaldama liitu või agregati.
• Materjaliseeritud liitvaated ja materjaliseeritud agregatiivvaated koos GRUPP BY klausi ei saa valida indeksiorganiseeritud tabelist.

5.3.8.5 Kiire värskenduse piirangud materiaalsed vaated ainult liidete jaoks

Sisetustatud päringud materiaalsed vaated ainult liidete ja ilma agregaatideta omavad järgmisi piiranguid kiire värskenduse jaoks:

• Kõik piirangud «Üldised piirangud kiire värskenduse jaoks«.
• Need ei saa sisaldada GRUPP BY klausi või agregaatide.
• Tabelite rowid kogu FROM loendis peavad ilmuma SELECT päringu loendis.
• Materjaliseeritud vaate logid peavad sisaldama rowid kõikide alustabelite FROM päringu loendis.
• Sa ei saa luua kiiresti värskendatavaid materjaliseeritud vaate mitmest tabelist, mille lihtsad liidud sisaldavad objekti tüübi veergu SELECT lausendis.

Samuti ei ole valitud värskendamise meetod optimaalselt tõhus, kui:

• Määrav päring kasutab välist liitu, mis käitub nagu siseviit. Kui määrav päring sisaldab sellist liitu, kaalu ümberkirjutamist määrava päringu sisu muutmiseks siseviiduks.
• The SELECT materjaliseeritud vaate loend sisaldab väljendeid mitmest tabelist.

5.3.8.6 Kiire värskenduse piirangud materiaalsed vaated agregaatide jaoks

Sisetustatud päringud materiaalsed vaated agregaatide või liidete jaoks omavad järgmisi piiranguid kiire värskenduse jaoks:

• Kõik piirangud «Üldised piirangud kiire värskenduse jaoks«.

Kiire värskendus on toetatud mõlema jaoks KAS COMMIT ja KAS NÕUDMINE materjaliseeritud vaated, kuid järgmised piirangud kehtivad:

• Kõik tabelid materiaalsete vaadete peavad olema materjaliseeritud vaate logid ja need logid peavad:
  • Sisaldama kõiki veerge tabelist, millega viidatakse materjaliseeritud vaates.
  • Spetsifitseerige ROWID ja KAASA ARVATUD UUTE VÄÄRTUSED.
  • Spetsifitseerige SEKVENTS klausi, kui tabelit oodatakse, et seal oleks segu sisestamisest/otsesest laadimisest, kustutamist ja uuendamist.

• Ainult SUM, COUNT, AVG, STDDEV, VARIANTS, MIN ja MAX toetatakse kiire värskenduse jaoks.
• COUNT(*) tuleb määrata.
• Agregeerimisfunktsioonid võivad esineda ainult väljendi kõige välimises osas. See tähendab, et kogud nagu AVG(AVG(x)) või AVG(x)+ AVG(x) ei ole lubatud.
• Iga aggregeerimise jaoks, nagu AVG(expr), peab vastav COUNT(expr) olema olemas. Oracle soovitab, et SUM(expr) oleks määratud.
• Kui VARIANCE(expr) või STDDEV(expr) on määratud, COUNT(expr) ja SUM(expr) tuleb määrata. Oracle soovitab, et SUM(expr *expr) oleks määratud.
• The SELECT veerg määratlemise päringus ei saa olla keeruline väljend mitmest põhiteabest. Võimalik lahendus sellele on kasutada pesastatud materialiseeritud vaadet.
• The SELECT loend peab sisaldama kõiki GRUPP BY veerge.
• Materialiseeritud vaade ei põhine ühel või enam eemalolevast tabelist.
• Kui kasutate CHAR andmetüüpi materialiseeritud vaate logi filtreerimise veergudes, peavad masteri saidi ja materialiseeritud vaate karakterikomplektid olema samad.
• Kui materialiseeritud vaates on üks järgmistest, siis toimub kiire värskendus ainult tavaliste DML sisestamiste ja otsekoormuste korral.
  • Materialiseeritud vaated koos MIN või MAX agregaatide
  • Materialiseeritud vaated, millel on SUM(expr) aga ilma COUNT(expr)
  • Materialiseeritud vaated ilma COUNT(*)

  Sellist materialiseeritud vaadet nimetatakse ainult sisestatavaks materialiseeritud vaateks.

• Materialiseeritud vaade, millel on MAX või MIN on kiire värskendatav pärast kustutamist või segatud DML-lauseid, kui tal ei ole WHERE See ei tohi viidata tabelile, millel on määratud
  Max/min kiire värskendus pärast kustutamist või segatud DML ei käitu sama moodi nagu ainult sisestatav juhtum. See kustutab ja uuesti arvutab maksimaalsed/minimaalsed väärtused mõjutatud gruppide jaoks. Peate olema teadlik selle soorituse mõjust.
• Materialiseeritud vaated, millel on nimetatud vaated või alampäringud FROM klauslis, võivad olla kiiresti värskendatud, tingimusel et vaated saab täielikult ühendada. Teabe saamiseks selle kohta, millised vaated mergivad, vaadake Oracle Database SQL Language Reference.
• Kui välist ühendumist ei ole, võite teha meelevaldseid valikuid ja ühendusi. WHERE See ei tohi viidata tabelile, millel on määratud
• Materjaliseeritud agregeeritud vaated koos välisühendustega on kiiresti värskendatavad pärast tavapärast DML-i ja otsekoormusi, tingimusel et ainult välisdiagramm on muudetud. Samuti peavad unikaalsed piirangud olema olemas sisendaabli ühendusveeru kohta. Kui on välisühendusi, peavad kõik ühendused olema seotud ANDja peavad kasutama võrdsus (=) operaatorit.
• Materjaliseeritud vaadete jaoks, millel on CUBE, ROLLUP, grupi komplektid või nende ühendamine, kehtivad järgmised piirangud:
  • The SELECT loend peaks sisaldama grupi eristajat, mis võib olla kas GROUPING_ID funktsioon kõigi GRUPP BY avaldiste või GROUPING funktsioonide jaoks, igaühe jaoks GRUPP BY avaldis. Näiteks, kui GRUPP BY materjaliseeritud vaate lause on «GRUPP BY CUBE(a, b)«, siis loend peaks sisaldama kas « SELECT GROUPING_ID(a, b)» või «GROUPING(a)GROUPING(b) AND » materjaliseeritud vaate kiireks värskendamiseks.» et materjaliseeritud vaade oleks kiire värskendatav.
  • GRUPP BY ei tohi tulemuseks olla mingeid dubleeritud grupitusi. Näiteks «GROUP BY a, ROLLUP(a, b)» ei ole kiiresti värskendatav, kuna see toob kaasa dubleeritud grupitused «(a), (a, b), JA (a)«.

5.3.8.7 Kiire värskenduse piirangud materjaliseeritud vaadete puhul, kus on UNION ALL

Materjaliseeritud vaated koos UNION ALL set operaator toetab VÄRSKENDUS KIIRE valikut, kui järgmised tingimused on täidetud:

• Määratlemise päring peab olema UNION ALL operaator tipus.

  The UNION ALL operaatorit ei tohi embedida alampäringusse, välja arvatud üks erand: UNION ALL võib olla alampäringus FROM lausendis, tingimusel et määratlemise päring on kujul SELECT * FROM (vaade või alampäring, millel on UNION ALL) nagu allolevas näites:

  LOO VAADE view_with_unionall KUNA
  (SELECT c.rowid crid, c.cust_id, 2 umarker
   FROM customers c WHERE c.cust_last_name = 'Smith'
   UNION ALL
   SELECT c.rowid crid, c.cust_id, 3 umarker
   FROM customers c WHERE c.cust_last_name = 'Jones');
  
  LOO MATERJALISEERITUD VAATETЁURNALL KIIRED VÄRSKENDUS NÕUDMISEL KUNA
  SELECT * FROM view_with_unionall;
  

  Pange tähele, et vaade view_with_unionall täidab kiire värskendamise nõudeid.

• Iga päringu blokis UNION ALL päring peab vastama kiiresti värskendatava materjaliseeritud vaate nõuetele, kus on koondandmed või kiiresti värskendatav materjaliseeritud vaade, kus on ühendused.

  Sobivad materjaliseeritud vaate logid peavad olema loodud tabelitele vastavalt nõuetele, mis on seotud vastava tüübi kiiresti värskendatava materjaliseeritud vaate jaoks.
  Pange tähele, et Oracle Database võimaldab ka erilist juhtumit, kus on üksik tabeli materjaliseeritud vaade, millel on ainult ühendused, tingimusel et ROWID veerg on hõlmatud SELECT loendis ja materjaliseeritud vaate logis. Seda näidatakse vaate määratlemise päringus view_with_unionall.

• The SELECT iga päringu loendis peab olema UNION ALL marker ning UNION ALL veerg peab igas UNION ALL haru puhul olema eristuva püsiva numbrilise või stringiga väärtusega. SELECT Edasi, marker veerg peab ilmuma samas järjestuses igaspäringu ploki loendis. Vaadake «UNION ALL Marker ja Päringu Ümberkirjutamine UNION ALL » täiendava teabe saamiseks markerite kohta.
• Mõned funktsioonid, nagu välised ühendused, ainult sisestamise koondandmete materjaliseeritud vaate päringud ja kaugteabelaadid, ei ole toetatud materjaliseeritud vaadetes, millel on UNION ALL. Pange tähele, et replikatsioonis kasutatavad materjaliseeritud vaated, mis ei sisalda ühendusi või koondandmeid, saavad olla kiiresti värskendatud, kui UNION ALL või kaugteabelaadid on kasutusel.
• Ühilduvuse algseadmise parameeter peab olema seadistatud 9.2.0 või kõrgemaks, et luua kiiresti värskendatav materjaliseeritud vaade koos UNION ALL.

Ma ei taha Oracle'i fänne solvata, kuid nende piirangute nimekirja põhjal tuleb mul tõdeda, et see mehhanism ei tundu olevat kirjutatud üldiselt, vaid nagu oleks igaühele antud võimalus kirjutada oma osa, milles igaüks tegi, mida oskas. Selle mehhanismi kasutamine tegelikus loogikas on nagu käimine miiniväljal. Igal hetkel võib sattuda miinile, sattudes ühele mitteilmsele piirangule. Kuidas see toimib, on samuti eraldi küsimus, kuid see jääb antud artikli raamesse.

Microsoft SQL Server

Lisa nõuded

Lisaks SET valikutele ja määratletud funktsioonide nõuetele peavad olema täidetud järgmised nõuded:

• Kasutaja, kes käivitab CREATE INDEX peab olema vaate omanik.
• Indeksi loomisel peab IGNORE_DUP_KEY valik olema seadistatud OFF (vaike väärtus).
• Tabeleid tuleb viidata kaheosaliste nimede kaudu, skeemaga.tabelinimi vaate definitsioonis.
• Kasutaja määratud funktsioonid, millele viidatakse vaates, peavad olema loodud WITH SCHEMABINDING valikuga.
• Vaates viidatud kõik kasutaja määratud funktsioonid peavad olema viidatud kaheosaliste nimede kaudu, <skeem>.<funktsioon>.
• Kasutaja määratud funktsiooni andmete ligipääsu omadus peab olema NO SQL, ja välise ligipääsu omadus peab olema NO.
• Ühised keelekäituse (CLR) funktsioonid võivad ilmuda vaate valikuloendis, kuid ei saa olla osa klastritud indeksi võtme määratlemisest. CLR funktsioonid ei tohi ilmuda vaate WHERE klauslis ega JOIN operatsiooni ON klauslis.
• CLR-funktsioonid ja CLR-kasutaja määratud tüüpide meetodid, mida kasutatakse vaate määratlemisel, peavad olema seatud nagu on näidatud järgmises tabelis.

  Omadus
  Märkus

  DETERMINISTLIK = TRUE
  Peab olema eksplitsiitselt deklareeritud Microsoft .NET Framework meetodi atribuudina.

  TÄPNE = TRUE
  Peab olema eksplitsiitselt deklareeritud .NET Framework meetodi atribuudina.

  ANDMEKÜSIMINE = EI SQL
  Määratakse, seadistades DataAccess atribuudiks DataAccessKind.None ja SystemDataAccess atribuudiks SystemDataAccessKind.None.

  VÄLJASPOLISED JUURDEPÄÄS = EI
  See omadus on vaikimisi EI CLR-rutiinide jaoks.

• Vaate peab looma kasutades WITH SCHEMABINDING valikuga.
• Vaate peab viitama ainult baustabelitele, mis asuvad samas andmebaasis nagu vaade. Vaade ei tohi viidata teistele vaadetele.
• Vaate määratlemise SELECT-klauslis ei tohi sisaldada järgmisi Transact-SQL elemente:

  COUNT
  ROWSET-funktsioonid (OPENDATASOURCE, OPENQUERY, OPENROWSET, JA OPENXML)
  VÄLJASPOLISED ühendused (VASAK, PAREM, või FULL)

  Tüvivaat (määratletud, täpsustades SELECT lausest FROM klauslis)
  Iseliitmine
  Veergude määratlemine kasutades SELECT * või SELECT

  .*

  DISTINCT
STDEV, STDEVP, VAR, VARP, või AVG
  Ühine tabeli väljend (CTE)

  float1, text, ntext, pilt, XML, või filestream veergud
  Alampäring
  OVER klausel, mis sisaldab järjestus- või kogumifunktsioone

  Täisteksti sõelad (CONTAINS, FREETEXT)
  SUM funktsioon, mis viitab nullitavale väljendile
  ORDER BY

  CLR kasutaja määratud agregaatfunktsioon
  TOP
CUBE, ROLLUP, või GROUPING SETS operaatorid

  MIN, MAX
UNION, VÄLJAS, või INTERSECT operaatorid
  TABLESAMPLE

  Tabelimuutujad
  VÄLJASPOLISED APPLY või RISTSÜND APPLY
PIVOT, UNPIVOT

  Sparse veergude komplektid
  Inline (TVF) või mitme lausestuse tabeliväärtuste funktsioonid (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 Indekseeritud vaade võib sisaldada float veerge; selliseid veerge ei tohi siiski lisada klastreeritud indeksi võtmesse.

  Kui GROUP BY olemasolekul peab VAATE määratlemine sisaldama COUNT_BIG(*) ja ei tohi sisaldada HAVING. Need GROUP BY piirangud kehtivad ainult indekseeritud vaate määratlemise kohta. Küsimus võib kasutada indekseeritud vaadet oma täitmisplaanis, isegi kui see ei rahulda neid GROUP BY piiranguid.
  Kui vaate määratlemine sisaldab GROUP BY slau, unikaalse klastreeritud indeksi võti võib viidata ainult määratud veergudele GROUP BY See ei tohi viidata tabelile, millel on määratud

  Siit on näha, et indiaanlasi ei kaasatud, kuna nad otsustasid järgida skeemi "teeme vähe, aga hästi". See tähendab, et neil on rohkem maamärke väljal, kuid nende paigutus on selgem. Kõige rohkem teeb mureks see piirang:

  Vaate peab viitama ainult baustabelitele, mis asuvad samas andmebaasis nagu vaade. Vaade ei tohi viidata teistele vaadetele.

  Meie terminoloogias tähendab see, et funktsioon ei saa viidata teisele materialiseeritud funktsioonile. See hävitab kogu ideoloogia täielikult.
  Samuti vähendab see piirang (ja edasi tekstis) oluliselt kasutusvõimalusi:

  Vaate määratlemise SELECT-klauslis ei tohi sisaldada järgmisi Transact-SQL elemente:

  COUNT
  ROWSET-funktsioonid (OPENDATASOURCE, OPENQUERY, OPENROWSET, JA OPENXML)
  VÄLJASPOLISED ühendused (VASAK, PAREM, või FULL)

  Tüvivaat (määratletud, täpsustades SELECT lausest FROM klauslis)
  Iseliitmine
  Veergude määratlemine kasutades SELECT * või SELECT

  .*

  DISTINCT
STDEV, STDEVP, VAR, VARP, või AVG
  Ühine tabeli väljend (CTE)

  float1, text, ntext, pilt, XML, või filestream veergud
  Alampäring
  OVER klausel, mis sisaldab järjestus- või kogumifunktsioone

  Täisteksti sõelad (CONTAINS, FREETEXT)
  SUM funktsioon, mis viitab nullitavale väljendile
  ORDER BY

  CLR kasutaja määratud agregaatfunktsioon
  TOP
CUBE, ROLLUP, või GROUPING SETS operaatorid

  MIN, MAX
UNION, VÄLJAS, või INTERSECT operaatorid
  TABLESAMPLE

  Tabelimuutujad
  VÄLJASPOLISED APPLY või RISTSÜND APPLY
PIVOT, UNPIVOT

  Sparse veergude komplektid
  Inline (TVF) või mitme lausestuse tabeliväärtuste funktsioonid (MSTVF)
  OFFSET

  CHECKSUM_AGG

  OUTER JOIN’id, UNION, ORDER BY ja muud on keelatud. Võib-olla oleks olnud lihtsam öelda, mida tohib kasutada, kui seda, mida ei tohi. Loend oleks tõenäoliselt palju lühem.

  Kokkuvõtteks: tohutu arv piiranguid igas (märgin, ärilise) SÜBDes vs mitte midagi (välja arvatud üks loogiline, mitte tehniline) LGPL tehnoloogias. Siiski tuleb märkida, et sellele mehhanismile rakendamine relatiivsuse loogikas on veidi keerulisem kui kirjeldatud funktsionaalses.

  Rakendus

  Kuidas see töötab? "Virtuaalse masinana" kasutatakse PostgreSQL-i. Siseselt on keeruline algoritm, mis tegeleb päringute koostamisega. Siin on allikas. Ja seal pole lihtsalt suur hulk heuristikaga, kus on palju if-eid. Nii et kui teil on paar kuud õppimiseks, võite proovida arhitektuuri mõista.

  Kas see töötab tõhusalt? Piisavalt tõhusalt. Kahjuks on seda raske tõestada. Võin vaid öelda, et kui vaadata tuhandeid päringuid, mis on suurtes rakendustes, siis keskmiselt on need tõhusamad kui hea arendaja omad. Suurepärane SQL-programmeerija võib kirjutada iga päringu tõhusamalt, kuid tuhandete päringute puhul ei ole tal lihtsalt motivatsiooni ega aega seda teha. Ainus, mida ma praegu tõhususe tõendina tuua saan, on see, et selle andmebaasi põhjal töötavad mitmed projektid ERP-süsteemid, kus on tuhandeid erinevaid MATERIALIZED funktsioone, tuhandete kasutajatega ja terabaidiste andmebaasidega, kus on sadu miljoneid kirjeid, töötades tavalise kahe protsessoriga serveris. Siiski võib igaüks, kes soovib, efektiivsust kontrollida/ümber lükata, laadides alla platvormi ja PostgreSQL, lülitades sisse SQL-päringute logimise ja proovides seal loogikat ja andmeid muuta.

  Järgmistes artiklites räägin ka sellest, kuidas funktsioonidele piiranguid seada, kuidas töötada seansimuudatustega ja palju muust.
  
  Allikas: habr.com

  
  

  Yuri Gagarin

  Artikli autor

  ProHosteris töötav tehniline spetsialist, kellel on üle kuue aasta kogemust serverite haldamises, VPN-lahendustes ja võrguturbes. Halden infrastruktuuri seadistamist ja tuge, jälgin teenuste stabiilsust ja rakendan lahendusi klientide andmete kaitsmiseks. Aitan ka jõudluse optimeerimisel ning kaasaegsete turva- ja privaatsusstandardite järgimisel.

  Me kasutame küpsiseid, et tagada parim kogemus meie veebisaidil. Jätkates saidi kasutamist, nõustute meie privaatsuspoliitikaga. Nõustuda
  Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster