Andmete lugemise ja kirjutamise tasakaalustamine andmebaasis

Eelnevas artiklis kirjeldasin andmebaasi kontseptsiooni ja rakendust, mis põhineb funktsioonidel, mitte tabelitel ja väliandmetel nagu relatsioonilistes andmebaasides. Seal on toodud palju näiteid, mis näitavad selle lähenemise eeliseid klassikalise ees. Paljud leidsid, et need olid piisavalt veenvad.

Selles artiklis näitan, kuidas selline kontseptsioon võimaldab kiiresti ja mugavalt tasakaalustada andmete kirjutamist ja lugemist andmebaasis ilma igasuguste muudatusteta töölogikas. Sarnast funktsionaalsust on proovitud rakendada kaasaegsetes kaubanduslikes andmebaasihaldussüsteemides (eriti Oracle ja Microsoft SQL Server). Artikli lõpus näitan, et sellel ei läinud just väga hästi.

Kirjeldus

Nagu varasemalt, alustan näidetest parima arusaamise nimel. Oletame, et peame rakendama loogikat, mis tagastab osakondade nimekirja koos töötajate arvu ja nende kogupalga.

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

Klass Departement 'Osakond';
nimi 'Nimetus' = ANDMED STRING[100] (Departement);

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

countEmployees 'Töötajate arv' (Department d) = 
    GROUP SUM 1 IF department(Employee e) = d;
salarySum 'Kogupalk' (Department d) = 
    GROUP SUM salary(Employee e) IF department(e) = d;

SELECT name(Department d), countEmployees(d), salarySum(d);

Selle päringu täitmise keerukus igas andmebaasis on võrreldav O(töötajate arvuga), kuna selle arvutamiseks tuleb skaneerida kogu töötajate tabel ja seejärel rühmitada nad osakondade kaupa. Samuti tuleb arvestada väikese lisandiga (arvame, et töötajaid on oluliselt rohkem kui osakondi) sõltuvalt valitud plaanist O(log töötajate arv) või O(osakondade arv) rühmitamise ja muu kohta.

Selge, et teostuskulud võivad erinevates andmebaasides olla erinevad, kuid keerukus ei muutu kuidagi.

Esi rakenduses loob funktsionaalne andmebaas ühte alampäringut, mis arvutab vajalikud väärtused osakonna järgi ja liidab seejärel osakondade tabeliga, et saada nimi. Siiski on iga funktsiooni deklareerimisel võimalik määrata spetsiaalne marker MATERIALIZED. Süsteem loob automaatselt vastava välja iga sellise funktsiooni jaoks. Funktsiooni väärtuse muutmisel muudetakse ka välja väärtust samas tehingus. Funktsiooni kutsumisel pöördutakse juba eelnevalt arvutatud välja poole.

Eriti kui määrata MATERIALIZED funktsioonide jaoks countEmployees ja salarySum, siis lisatakse osakondade loendi tabelisse kaks välja, kuhu salvestatakse töötajate arv ja nende kogupalk. Iga töötaja, nende palga või osakondade kuuluvuse muutumisel muudab süsteem automaatselt nende väljade väärtusi. Ülaltoodud päring pöördub otse nende väljade poole ja täidetakse O(osakondade arv).

Millised on piirangud? Ainult üks: sellisel funktsioonil peab olema lõplik sisendväärtuste arv, mille jaoks on selle väärtus määratud. Vastasel juhul oleks võimatu koostada tabelit, mis salvestab kõik tema väärtused, kuna ei saa olla tabelit, kus on lõpmatu arv ridu.

Näide:

employeesCount 'Töötajate arv palgaga > N' (Department 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 väärtustele, näiteks sobib iga negatiivne väärtus. Seega ei saa sellele määrata MATERIALIZED. Seega on see loogiline, mitte tehniline piirang (st mitte sellepärast, et me ei suudaks seda realiseerida). Muus osas pole mingeid piiranguid. Saab kasutada rühmitamisi, sorteerimisi, AND ja OR, PARTITION, rekursioone jne.

Näiteks eelmise artikli ülesandes 2.2 saab määrata MATERIALIZED mõlema funktsiooni jaoks:

ostetud 'Ostis' (Klient c, Toode p, KOGUS y) = 
    RÜHM SUM sum(Detaail d) KUI 
        klient(keerake(d)) = c JA 
        toode(d) = p JA 
        välja võttaAasta(date(keerake(d))) = y MATERIALISEERITUD;
hinnang 'Hinnang' (Klient c, Toode p, KOGUS y) = 
    PARTITSIOON SUM 1 KORDA MITTE KUI ostetud(c, p, y), p KLIENDI, y MATERIALISEERITUD;
VALI kontaktNimi(Klient c), nimi(Toode p) KUIDAS hinnang(c, p, 1997) < 3;


Süsteem loob ise ühe tabeli tüüpide võtmetega Klient, Toode ja INTEGER, lisab sinna kaks välja ja uuendab nende väärtusi igasuguste muudatuste korral. Edasiste päringute puhul nende funktsioonide osas ei toimu nende arvutamist, vaid loetakse vastavatest väljades väärtusi.

Selle mehhanismi abil on võimalik näiteks loobuda rekursioonidest (CTE) päringutes. Näiteks vaatleme gruppe, mis moodustavad puu child/parent suhte kaudu (igal grupil on viide oma vanemale):

vanem = ANDME Grupp (Rühm);


Funktsionaalsetes andmebaasides saab rekursiivse loogika määratleda järgmiselt:

tase (Rühma laps, Rühma vanem) = REKURSIOON 1l KUI laps ON Rühm JA vanem == laps
                                                             SAMM 2l KUI vanem == vanem($vanem);
isVanem (Rühma laps, Rühma vanem) = TÕENE KUI tase(laps, vanem) MATERJALISEERITUD;


Kuna funktsioonile isParent on määratud MATERIALIZED, siis selle jaoks luuakse tabel kahe võtmega (grupiga), kus väli isParent on tõene ainult siis, kui esimene võti on teise järeltulija. Selle tabeli ridade arv on võrdne gruppide arvu ja puu keskmise sügavuse korrutisega. Kui on vaja näiteks arvutada teatud grupi järeltulijate arvu, saab sellele funktsioonile viidata:

lasteArv (Grupi g) = GRUPI SUM 1 KUI isVanem(Grupi laps, g);


SQL-päringus ei ole CTE-d. Selle asemel on olemas lihtne GROUP BY.

Selle mehhanismi abil on samuti lihtne vajadusel andmebaasi denormaliseerida:

Klass Tellimus 'Tellimus';
kuupäev 'Kuupäev' = DATA DATE (Tellimus);

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

Kasutades funktsiooni date tellimuse read loetakse tabelist, kus on väli, millel on indeks. Kui tellimuse kuupäeva muudetakse, arvutab süsteem automaatselt denormaliseeritud kuupäeva uuesti.

Eelised

Milliseks on kogu see mehhanism vajalik? Klassikalistes andmebaasides, ilma päringute ümberkirjutamiseta, saavad arendajad või DBA-d vaid indekseid muuta, statistikat määrata ja suunata päringute planeerijat, kuidas neid teostada (HINT’e on ainult kommertsandmebaasides). Ükskõik kui palju nad vaeva näevad, ei saa nad esimest päringut artiklis täita arvu võrra O (osakondade arv) ilma päringute muutmise ja triggerite kirjutamiseta. Kuid ettepanekus, mida esitatakse, ei pea arendamise käigus muretsema andmete säilitamise struktuuri ja selle üle, milliseid agregaatfunktsioone kasutada. Seda kõike saab rahulikult muudatusi teha juba töö käigus.

Praktikas näeb see välja järgmine. Mõned inimesed arendavad otse ülesande põhjal loogikat. Nad ei mõista ei algoritme ja nende keerukust, ei täitmisplaane, ei join-tüüpe, ega ühtegi muud tehnilist aspekti. Need inimesed on pigem ärianalüütikud kui arendajad. Seejärel lähevad kõik need asjad testimisele või kasutusse. Lülitatakse sisse pikaajaliste päringute logimine. Kui leitakse pikk päring, siis otsustab selle üle juba teised inimesed (tehnilisemad — sisuliselt DBA-d), et aktiveerida MATERIALIZED mingi vahefunktsiooni jaoks. Sellega aeglustub veidi kirjutamine (sest on vajalik lisavälja värskendamine tehingus). Kuid see kiirendab oluliselt mitte ainult seda päringut, vaid ka kõiki teisi, mis kasutavad seda funktsiooni. Otsustamine, milline funktsioon just materialiseerida, on suhteliselt lihtne. Kaks peamist parameetrit: võimalike sisendväärtuste arv (just nii palju kirjeid on vastavas tabelis) ja kui sageli seda kasutatakse teistes funktsioonides.

Analoogid

Kaasaegsetes kommertslikes andmebaasihaldussüsteemides on sarnased mehhanismid: MATERIALIZED VIEW FAST REFRESH (Oracle) ja INDEXED VIEW (Microsoft SQL Server). PostgreSQL-s ei oska MATERIALIZED VIEW värskendust teostada tehingus, vaid ainult nõudmisel (ja veel väga ranged piirangud), seega seda ei arvestata. Kuid nendel on mitmeid probleeme, mis piiravad oluliselt nende kasutust.

Esiteks, materialiseerimine on lubatud ainult siis, kui on juba loodud tavaline VIEW. Vastasel juhul tuleb üle kirjutada kõik muud päringud, et pöörduda uue loodud vaate poole, et kasutada seda materialiseerimist. Või jätta kõik nii, nagu on, kuid see on vähemalt ebaefektiivne, kui on olemas teatud juba ette arvutatud andmed, kuid paljusid päringuid ei kasuta neid alati, vaid arvutavad uuesti.

Teiseks, neil on palju piiranguid:

Oracle

5.3.8.4 Üldised piirangud kiireks värskendamiseks

Materialiseeritud vaate määratlev päring on järgmistele piirangutele allutatud:

• Materialiseeritud vaade ei tohi sisaldada viiteid mitte-korratavatele avaldustele nagu SYSDATE ja ROWNUM.
• Materialiseeritud vaade ei tohi sisaldada viiteid RAW või LONG RAW andmetüü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. MODEL
• See ei tohi sisaldada HAVING See ei tohi viidata tabelile, millel on määratud
• See ei tohi sisaldada klausel alampäringuga. See ei tohi sisaldada pesaküsimusi, millel on
• ANY ALL, , võiNOT EXISTS EXISTS.
• See ei tohi sisaldada [START WITH …] ÜHENDAGE BY See ei tohi viidata tabelile, millel on määratud
• See ei tohi sisaldada mitut detailtabelit erinevates kohtades.
• KAS COMMIT materjaliseeritud vaated ei tohi omada kauguses detailtabeleid.
• Sisemised materjaliseeritud vaated peavad sisaldama liitumist või agregaati.
• Materjaliseeritud liitumisvaated ja materjaliseeritud agregaativaated koos GRUPPIDA KOHES klausel ei tohi valida indeksiga korraldatud tabelit.

5.3.8.5 Kiire värskenduse piirangud materjaliseeritud vaadete suhtes, millel on ainult liidud

Materjaliseeritud vaadete määratlemiseks, millel on ainult liidud ja ei sisaldada agregaate, kehtivad järgmised piirangud kiire värskendamise osas:

• Kõik piirangud «Üldised piirangud kiirele värskendusele«.
• Nad ei tohi sisaldada GRUPPIDA KOHES klausuure ega agregaate.
• Tabelite ridade ID-d KUST loend peab ilmuma SELECT päringu nimekirja.
• Materjaliseeritud vaate logid peavad eksisteerima kõigi aluste tabelite ridade ID-dega KUST päringu nimekirja.
• Te ei saa luua kiiresti värskendatavat materjaliseeritud vaadet mitmest tabelist, kus on lihtsad liidud, mis sisaldavad objekti tüüpi veergu SELECT lausendis.

Samuti ei ole valitud värskendamismeetod optimaalselt efektiivne, kui:

• Määratlemiseks kasutatav päring kasutab välist liitu, mis käitub nagu sisemine liit. Kui määratlev päring sisaldab sellist liitu, kaaluge määratleva päringu ümbersõnastamist, et see sisaldaks sisemist liitu.
• Materjaliseeritud vaate SELECT loend sisaldab väljendeid veergudest, mis pärinevad mitmest tabelist.

5.3.8.6 Kiire värskenduse piirangud materjaliseeritud vaadete suhtes, millel on agregaadid

Materjaliseeritud vaade määratleb päringud, millel on agregaadid või liidud, kehtivad järgmised piirangud kiire värskendamise osas:

• Kõik piirangud «Üldised piirangud kiirele värskendusele«.

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

• Kõik tabelid materjaliseeritud vaates peavad omama materjaliseeritud vaate logisid, ja materjaliseeritud vaate logid peavad:
  • Sisaldama kõiki veerge tabelist, mis on viidatud materjaliseeritud vaates.
  • Osutama ROWID ja KATMA UUTE VÄÄRTUSTE.
  • Osutama JÕUD klausus, kui tabelil on oodata sisestuste/otsese laadimise, kustutamise ja värskenduste segu.

• Ainult SUMMA, LOEND, AVG, STDDEV, VARIANTS, MIN ja MAX toetatakse kiire värskenduse jaoks.
• LOEND(*) peab olema määratud.
• Agregaadifunktsioonid peavad toimuma ainult väljendi väliskihina. See tähendab, et agregaadid, nagu AVG(AVG(x)) või AVG(x)+ AVG(x) ei ole lubatud.
• Iga agregaadi puhul nagu AVG(expr), vastav COUNT(expr) peab olema olemas. Oracle soovitab, et SUM(expr) peaks olema määratud.
• Kui VARIANTS(expr) või STDDEV(expr) on määratud, COUNT(expr) ja SUM(expr) peab olema määratud. Oracle soovitab, et SUM(expr *expr) peaks olema määratud.
• Materjaliseeritud vaate SELECT veerg määratlemise päringus ei tohi olla keeruline väljend, mis sisaldab veerge mitmest alustan tabelist. Üks võimalik tööstuslahendus on kasutada sisemist materjaliseeritud vaadet.
• Materjaliseeritud vaate SELECT loend peab sisaldama kõiki GRUPPIDA KOHES veerge.
• Materjaliseeritud vaade ei põhine ühel või mitmel kaugtabelil.
• Kui kasutate CHAR andmetüüpi materjaliseeritud vaate logi filterveergudes, peavad meistri koha ja materjaliseeritud vaate sümbolikoodid olema samad.
• Kui materjaliseeritud vaadel on üks järgmistest, siis kiire värskendamine on toetatud ainult konventsionaalsete DML sisestuste ja otse laadimiste korral.
  • Materjaliseeritud vaated, millel on MIN või MAX agregaadid
  • Materjaliseeritud vaated, millel on SUM(expr) kuid ei ole COUNT(expr)
  • Materjaliseeritud vaated ilma LOEND(*)

  Sellist materjaliseeritud vaadet nimetatakse ainult sisestamismaterjaliseeritud vaateks.

• Materjaliseeritud vaade, millel on MAX või MIN on kiiresti värskendatav pärast kustutamist või segatud DML-lauseid, kui sellel ei ole KUS See ei tohi viidata tabelile, millel on määratud
  Maksimalne/minimaalne kiire värskendus pärast kustutamist või segatud DML ei käitu sama moodi nagu ainult sisestamise puhul. See kustutab ja arvutab uuesti maksimaalsed/minimaalsed väärtused mõjutatud gruppide jaoks. Te peate olema teadlik selle toimivuse mõjust.
• Materjaliseeritud vaated, millel on nimetatud vaated või alampäringud lauses KUST võivad olla kiiresti värskendatavad, tingimusel et vaated on täielikult ühendatud. Teave selle kohta, millised vaated saavad ühendatud, vaadake Oracle Database SQL Keele Viidatud.
• Kui puuduvad välist liidud, võite olla arengulised valikud ja liidud. KUS See ei tohi viidata tabelile, millel on määratud
• Materjaliseeritud agregaadivaated koos välist ühendustega on kiirelt värskendatavad pärast tavalisi DML ja otselaadimisi, tingimusel et ainult välistabelit on muudetud. Samuti peavad ainulaadsed piirangud olema olemas sisemise ühendustabeli ühendusveergude jaoks. Kui on olemas välishoid, peavad kõik ühendused olema ühendatud JAja peavad kasutama võrdsuse (=) operaatorit.
• Materjaliseeritud vaadete puhul, millel on KUBE, ROLLUP, grupivälja seeriate või nende kokkuliitmiste puhul kehtivad järgmised piirangud:
  • Materjaliseeritud vaate SELECT loendis peaks olema grupeerimise eristaja, mis võib olla kas GROUPING_ID funktsioon kõikide GRUPPIDA KOHES avaldiste või GROUPING funktsioonide puhul, üks igaühe jaoks GRUPPIDA KOHES avaldis. Näiteks, kui GRUPPIDA KOHES materjaliseeritud vaate klauses on «GRUPPIDA KOHES KUBE(a, b)«, peaks loendis olema kas « SELECT GROUPING_ID(a, b)» või «GROUPING(a)GROUPING(b) JA » et materjaliseeritud vaade oleks kiiresti värskendatav.ei tohi põhjustada mingeid dubleeritud grupeerimisi. Näiteks, «
  • GRUPPIDA KOHES GROUP BY a, ROLLUP(a, b)» ei ole kiiresti värskendatav, kuna see põhjustab dubleeritud grupeerimisi «(a), (a, b), JA (a)5.3.8.7 Kiire värskenduse piirangud materjaliseeritud vaadetele, millel on UNION ALL«.

Materjaliseeritud vaated, millel on

UNION kogumi operaator, toetavad , või VÄRSKENDUS KIIRE valikut, kui järgmised tingimused on täidetud: Määrava päringu tipus peab olema

• operaator. kogumi operaator, toetavad , või operaatorit ei tohi sügavale päringusseEmbedida, välja arvatud üks erand:

  Materjaliseeritud vaate kogumi operaator, toetavad , või võib olla alampäringus kogumi operaator, toetavad , või klauses, tingimusel et määrav päring on vormis KUST SELECT * FROM (vaade või alampäring koos ) nagu allolevas näites: kogumi operaator, toetavad , võiLOO VAATE view_with_unionall AS (VALI c.rowid crid, c.cust_id, 2 umarker FROM customers c KUS c.cust_last_name = 'Smith' UNION ALL VALI c.rowid crid, c.cust_id, 3 umarker KLIENTID c KUS c.cust_last_name = 'Jones');LOO MATERJALISEERITUD VAATE unionall_inside_view_mv VÄRSKENDUS KIIRE NÕUDMISEL NAGU VALI * FROM view_with_unionall;

  Pange tähele, et vaade
  

  view_with_unionall rahuldab kiire värskenduse nõudeid. Iga päringu plokk peaks rahuldama materjaliseeritud vaate kiire värskenduse nõudeid agregaatide või kiire värskenduse nõudeid ühendustega.

• Asjakohased materjaliseeritud vaate logid peavad olema loodud tabelite jaoks, nagu on nõutud vastava tüübi kiire värskendusega materjaliseeritud vaate jaoks. kogumi operaator, toetavad , või Pange tähele, et Oracle Database lubab ka erijuhtume, kus on olemas ainult üks tabeli materjaliseeritud vaade koos ühendustega, tingimusel et

  veerg on sisaldatud
  loendis ja materjaliseeritud vaate logis. See on näidatud vaate määrava päringu ROWID loend sees olev päring peab sisaldama SELECT märker, ja veerg peab olema igas rahuldab kiire värskenduse nõudeid..

• Materjaliseeritud vaate SELECT harude eristamiseks üksikasjalik alates logisid. Edasi, märker veerg peab ilmuma igasuguses ortoossaas iga küsimuses. Vaadake « kogumi operaator, toetavad , või UNION ALL Marker ja Päringu Ümberkirjutamine kogumi operaator, toetavad , või » rohkem teavet märkerite kohta. kogumi operaator, toetavad , või Mõned funktsioonid, nagu välised ühendused, ainult sisestamise agregaatide materjaliseeritud vaate päringud ja kaugmootorid ei ole toetatud materjaliseeritud vaadetes SELECT . Pange tähele, et materjaliseeritud vaated, mida kasutatakse replikatsioonis, mis ei sisalda ühendusi või agregaate, võivad olla kiiresti värskendatud, kuivõi kaugmootoreid kasutatakse.Ühildav algparameeter peab olema seatud 9.2.0 või kõrgemale, et luua kiiresti värskendatav materjaliseeritud vaate. kogumi operaator, toetavad , või märgid.
• Mõned funktsioonid, nagu välimised liitmisoperatsioonid, ainult sisestatavakujundistevaade päringud ja kaugfailid, ei ole toetatud materjaliseeritud vaadete jaoks, millel on kogumi operaator, toetavad , või. Tähelepanu, et materjaliseeritud vaated, mida kasutatakse replikatsioonis, milles ei ole ühendusi ega kokkuvõtteid, saavad kiirelt värskendatavaks, kui kogumi operaator, toetavad , või või kaugfailid on kasutusel.
• Ühilduvuse käivitamise parameeter peab olema seadistatud 9.2.0 või kõrgemale, et luua kiiresti värskendatav materjaliseeritud vaade, millel on kogumi operaator, toetavad , või.

Ma ei taha Oracle'i fänne solvata, kuid arvestades nende piirangute loetelu, jääb mulje, et see mehhanism on kirjutatud mitte üldise juhtumi jaoks, kasutades mingit mudelit, vaid kümnete miinuste, kus igale isikule anti võimalus kirjutada oma haru, ja igaüks neist tegi, mis suutis. Selle mehhanismi kasutamine reaalses loogikas on nagu minev minevikus ei jäädud, juhul kui satud ühele ebamugavale piirangule. Kuidas see töötab — on ka eraldi teema, aga see jääb selle artikli raamesse.

Microsoft SQL Server

Lisatingimused

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

• Kasutaja, kes teostab CREATE INDEX peab olema vaate omanik.
• Kui loote indeksi, peab IGNORE_DUP_KEY valik olema seadistatud OFF-ks (vaikeväärtus).
• Tabeleid tuleb viidata kaheosaliste nimedega, schema.tablename vaate määratlemises.
• Kasutaja määratletud funktsioonid, mida vaates viidatakse, peavad olema loodud kasutades WITH SCHEMABINDING valikut.
• Iga kasutaja määratletud funktsioon, mida vaates viidatakse, peab olema viidatud kaheosaliste nimedega, <schema>.<function>.
• Kasutaja määratletud funktsiooni andmete juurdepääsu omadus peab olema NO SQL, ja välist juurdepääsu omadus peab olema NO.
• Ühise keele ajakava (CLR) funktsioonid võivad ilmuda vaate valikute loendis, kuid ei saa olla osa klastrisse indeksivõti määratlemise kohta. CLR funktsioonid ei saa ilmneda vaate WHERE klauslis ega JOIN operatsiooni ON klauslis.
• CLR funktsioonid ja CLR kasutaja määratletud tüüpide meetodid, mida kasutatakse vaate määratlemisel, peavad olema seadistatud nagu näidatud järgmises tabelis.

  Omadus
  Märkus

  DETERMINISTIC = TRUE
  Peab olema deklaratsioonina märgitud Microsoft .NET Framework meetodi atribuudiks.

  PRECISE = TRUE
  Peab olema deklaratsioonina märgitud .NET Framework meetodi atribuudiks.

  DATA ACCESS = NO SQL
  Määratakse, seadistades DataAccess atribuudi väärtuseks DataAccessKind.None ja SystemDataAccess atribuudi väärtuseks SystemDataAccessKind.None.

  EXTERNAL ACCESS = NO
  See omadus on vaikeväärtusena NO CLR rutiinide jaoks.

• Vaade peab olema loodud kasutades WITH SCHEMABINDING valikut.
• Vaade peab viitama ainult aluskaartidele, mis asuvad sama andmebaasi sees kui vaade. Vaade ei saa viidata teistele vaadetele.
• Vaate määratlemise SELECT lauses ei tohi sisaldada järgmisi Transact-SQL elemente:

  LOEND
  ROWSET-funktsioonid (OPENDATASOURCE, OPENQUERY, OPENROWSET, JA OPENXML)
  VÄLJAS liitumised (VASAK, PAREMNOT TÄIELIK)

  Tuletatud tabel (määratletud, määrates otse SELECT lausesse) KUST Ishalud
  Määratleda veerge, kasutades
  SELECT * SELECT <table_name>.* või DISTINCT

  STDEV
STDEVP, VAR, VARP, Üksik tabeli väljund (CTE)NOT AVG
  float

  tekst1, ntext, XML, image, filestreamNOT veergudest Alamküsimus
  ÜLE
  lausest, mis sisaldab järjestamis- või agregaatakna funktsioone Täisteksti määratlused (

  CONTAINSFREETEXT, funktsioon, mis viitab nullitavale väljendile)
  SUMMA KORRALDA BY
  CLR kasutaja määratletud agregaatfunktsioon

  TOP
  GRUPP IMESED
KUBE, ROLLUPNOT operaatorid ERINEVUS

  MIN, MAX
kogumi operaator, toetavad, INTERSECTNOT TABLESAMPLE ERINEVUS
  Tabeli muutuja

  VÄLJAS KASUTA
  RISTI KASUTA või PIVOT
UNPIVOT, Sparsse veergude komplektid

  Inline (TVF) või mitme avaldise tabeli väärtuse funktsioonid (MSTVF)
  OFFSET
  CHECKSUM_AGG

  1 Indekseeritud vaade võib sisaldada

  veerge; kuid selliseid veerge ei saa lisada klastrisse indeksivõti. tekst GRUPP BY

• Kui on olemas, vaate määratlemine peab sisaldama COUNT_BIG(*) ja ei tohi sisaldada . Need klausel alampäringuga.piirangud kehtivad ainult indekseeritud vaate määratlemise kohta. Küsitav saab kasutada indekseeritud vaadet oma käitamisplaanis, isegi kui see ei vasta sellele on olemas, vaate määratlemine peab sisaldama piirangud. on olemas, vaate määratlemine peab sisaldama Kui vaate määratlemine sisaldab a
• Kui vaate määratlemine sisaldab on olemas, vaate määratlemine peab sisaldama tingimus, ainulaadse klastriga indeksi võti saab viidata ainult määratud veergudele on olemas, vaate määratlemine peab sisaldama See ei tohi viidata tabelile, millel on määratud

Siit on näha, et indusi ei paelunud, kuna nad otsustasid teha skeemi „teeme vähe, aga hästi“. See tähendab, et neil on väljal rohkem miine, kuid nende paigutus on selgem. Kõige rohkem häirib see piirang:

Vaade peab viitama ainult aluskaartidele, mis asuvad sama andmebaasi sees kui vaade. Vaade ei saa viidata teistele vaadetele.

Meie terminoloogias tähendab see, et funktsioon ei saa viidata teisele materialiseeritud funktsioonile. See peab kogu ideoloogia juureni.
Samuti vähendab see piirang (ja edasi tekstis) kasutusvõimalusi väga palju:

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

LOEND
ROWSET-funktsioonid (OPENDATASOURCE, OPENQUERY, OPENROWSET, JA OPENXML)
VÄLJAS liitumised (VASAK, PAREMNOT TÄIELIK)

Tuletatud tabel (määratletud, määrates otse SELECT lausesse) KUST Ishalud
Määratleda veerge, kasutades
SELECT * SELECT <table_name>.* või DISTINCT

STDEV
STDEVP, VAR, VARP, Üksik tabeli väljund (CTE)NOT AVG
float

tekst1, ntext, XML, image, filestreamNOT veergudest Alamküsimus
ÜLE
lausest, mis sisaldab järjestamis- või agregaatakna funktsioone Täisteksti määratlused (

CONTAINSFREETEXT, funktsioon, mis viitab nullitavale väljendile)
SUMMA KORRALDA BY
CLR kasutaja määratletud agregaatfunktsioon

TOP
GRUPP IMESED
KUBE, ROLLUPNOT operaatorid ERINEVUS

MIN, MAX
kogumi operaator, toetavad, INTERSECTNOT TABLESAMPLE ERINEVUS
Tabeli muutuja

VÄLJAS KASUTA
RISTI KASUTA või PIVOT
UNPIVOT, Sparsse veergude komplektid

Inline (TVF) või mitme avaldise tabeli väärtuse funktsioonid (MSTVF)
OFFSET
CHECKSUM_AGG

1 Indekseeritud vaade võib sisaldada

OUTER JOINS, UNION, ORDER BY ja muud on keelatud. Võib-olla oleks lihtsam öelda, mida võib kasutada, kui see, mida ei saa. Nimekiri oleks tõenäoliselt palju lühem.

Kokkuvõtteks: tohutu hulk piiranguid igas (märgin kommertslikus) andmebaasis vs mitte mingeid (välja arvatud üks loogiline, mitte tehniline) LGPL tehnoloogias. Siiski tuleb märkida, et selle mehhanismi rakendamine relatsioonilises loogikas on veidi keerulisem kui kirjeldatud funktsionaalses.

Rakendamine

Kuidas see töötab? „Virtuaalse masinana“ kasutatakse PostgreSQL-i. Seal sees on keeruline algoritm, mis tegeleb päringute koostamisega. Siit allikas kood. Ja seal ei ole lihtsalt suur hulk heurstikaid koos hunniku if-idega. Nii et kui on paar kuud aega uurimiseks, siis võite proovida aru saada arhitektuurist.

Kas see töötab tõhusalt? Piisavalt tõhusalt. Kahjuks on seda raske tõestada. Võin öelda, et kui vaadata tuhandeid päringuid, mis on suurtes rakendustes, siis keskmiselt on need efektiivsemad kui hea arendaja katsetused. Suurepärane SQL-programmeerija võib kirjutada mistahes päringu efektiivsemalt, kuid tuhande päringu puhul pole tal lihtsalt motivatsiooni ega aega seda teha. Ainus, mida ma praegu tõhususe tõestamiseks tuua saan, on see, et selle andmebaasi platvormile rajatud töökohad töötavad ERP-süsteemid, kus on tuhandeid erinevaid MATERIALIZED funktsioone, tuhandete kasutajatega ja terabaidiste andmebaasidega, kus on sadu millioneid kirjeid, töötades tavalisel kahetuumalisel serveril. Siiski võib iga soovija kontrollida/keelata efektiivsust, laadides alla platvormi ja PostgreSQL, ülendades SQL-päringute logimise ja proovides seal juhtida loogikat ja andmeid.

Järgmistes artiklites räägin ka, kuidas seadistada piiranguid funktsioonidele, töötada seanssidega ja palju muud.

Allikas: habr.com