ProHoster > Blog > Administrazioa > Datu-basean idazketak eta irakurketak orekatzea

Datu-basean idazketak eta irakurketak orekatzea

Datu-basean idazketak eta irakurketak orekatzea
Aurrekoan Artikulu Funtzioetan oinarrituta eraikitako datu-base baten kontzeptua eta ezarpena deskribatu nuen, datu-base erlazionaletan bezala taulak eta eremuak baino. Ikuspegi honek klasikoarekiko dituen abantailak erakusten dituzten adibide ugari eman zituen. Askok ez zuten nahikoa konbentzitzen.

Artikulu honetan, kontzeptu honek datu-basean idazketak eta irakurketak azkar eta erosotasunez orekatzeko aukera ematen dizun erakutsiko dut, funtzionamendu-logikan inolako aldaketarik gabe. Antzeko funtzionaltasuna DBMS komertzial modernoetan inplementatzen saiatu da (bereziki, Oracle eta Microsoft SQL Server). Artikuluaren amaieran erakutsiko dut egin zutena, nolabait esateko, ez zela oso ondo atera.

Description

Lehen bezala, hobeto ulertzeko deskribapena adibideekin hasiko dut. Demagun sailen zerrenda bat itzuliko duen logika ezarri behar dugula langile kopuruarekin eta soldata osoa.

Datu-base funtzional batean honela izango litzateke:

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

Kontsulta hau edozein DBMStan exekutatzeko konplexutasuna baliokidea izango da O (langile kopurua)izan ere, kalkulu horrek langileen taula osoa eskaneatu eta gero sailka taldekatzea eskatzen du. Aukeratutako planaren arabera osagarri txiki batzuk ere egongo dira (departamenduak baino askoz langile gehiago daudela uste dugu). O (langile kopuruaren erregistroa) edo O (sail kopurua) taldekatzeko eta abar.

Argi dago exekuzio-gastuak desberdinak izan daitezkeela DBMS desberdinetan, baina konplexutasuna ez da inola ere aldatuko.

Proposatutako inplementazioan, DBMS funtzionalak sailerako beharrezko balioak kalkulatuko dituen azpikontsulta bat sortuko du eta, ondoren, JOIN bat egingo du saileko taularekin izena lortzeko. Hala ere, funtzio bakoitzerako, deklaratzerakoan, MATERIALIZATU marka berezi bat ezar daiteke. Sistemak automatikoki sortuko du funtzio bakoitzari dagokion eremua. Funtzio baten balioa aldatzean, eremuaren balioa ere aldatuko da transakzio berean. Funtzio honetara sartzean, aurrez kalkulatutako eremura sartuko da.

Bereziki, funtzioetarako MATERIALIZED ezartzen baduzu zenbatuLangileak ΠΈ soldataSuma, orduan bi eremu gehituko zaizkio sailen zerrenda duen taulari, eta bertan langile kopurua eta soldata osoa gordeko dira. Langileak, soldatak edo saileko afiliazioak aldatzen diren bakoitzean, sistemak automatikoki aldatuko ditu eremu horien balioak. Goiko kontsulta eremu horietara zuzenean sartuko da eta bertan exekutatu egingo da O (sail kopurua).

Zeintzuk dira murrizketak? Gauza bakarra: funtzio horrek bere balioa definitzen duen sarrerako balio kopuru finitu bat izan behar du. Bestela, ezinezkoa izango da bere balio guztiak gordetzen dituen taula bat eraikitzea, ezin baita errenkada kopuru infinitua duen taularik egon.

Adibidea:

employeesCount β€˜ΠšΠΎΠ»ΠΈΡ‡Π΅ΡΡ‚Π²ΠΎ ΡΠΎΡ‚Ρ€ΡƒΠ΄Π½ΠΈΠΊΠΎΠ² Ρ Π·Π°Ρ€ΠΏΠ»Π°Ρ‚ΠΎΠΉ > N’ (Department d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;

Funtzio hau N-ren balio kopuru infinitu baterako definitzen da (adibidez, edozein balio negatibo egokia da). Horregatik, ezin duzu MATERIALIZATUA jarri. Beraz, muga logiko bat da, ez teknikoa (hau da, ez inplementatu ezin izan dugulako). Bestela, ez dago murrizketarik. Taldekatzeak, ordenatzea, ETA eta EDO, PARTITION, errekurtsioa eta abar erabil ditzakezu.

Adibidez, aurreko artikuluko 2.2 arazoan, MATERIALIZED jar dezakezu bi funtzioetan:

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;

Sistemak berak taula bat sortuko du mota gakoekin Customer, Produktuen ΠΈ ZENBATUA, bi eremu gehituko dizkio eta eremuen balioak eguneratuko ditu edozein aldaketarekin. Funtzio horiei dei gehiago egiten zaizkienean, ez dira kalkulatuko, baizik eta balioak dagozkien eremuetatik irakurriko dira.

Mekanismo hau erabiliz, adibidez, errekurtsioak (CTE) ken ditzakezu kontsultetan. Bereziki, kontuan hartu haur/guraso harremana erabiliz zuhaitz bat osatzen duten taldeak (talde bakoitzak bere gurasoarekiko esteka du):

parent = DATA Group (Group);

Datu-base funtzional batean, errekurtsio-logika honela zehaztu daiteke:

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;

Funtziorako geroztik Gurasoa da MATERIALIZATUA markatuta dago, orduan bi gako (talde) dituen taula bat sortuko da, eta bertan eremua Gurasoa da egia izango da lehenengo gakoa bigarrenaren seme-alaba bada bakarrik. Taula honetako sarrera kopurua zuhaitzaren batez besteko sakonerarekin biderkatuta dagoen talde kopuruaren berdina izango da. Adibidez, talde jakin bateko ondorengoen kopurua zenbatu behar baduzu, funtzio hau erabil dezakezu:

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

SQL kontsultan ez da CTErik egongo. Horren ordez GROUP BY soil bat egongo da.

Mekanismo hau erabiliz, datu-basea erraz desnormaliza dezakezu behar izanez gero:

CLASS Order 'Π—Π°ΠΊΠ°Π·';
date 'Π”Π°Ρ‚Π°' = DATA DATE (Order);

CLASS OrderDetail 'Π‘Ρ‚Ρ€ΠΎΠΊΠ° Π·Π°ΠΊΠ°Π·Π°';
order 'Π—Π°ΠΊΠ°Π·' = DATA Order (OrderDetail);
date 'Π”Π°Ρ‚Π°' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;

Funtzio bati deitzean data eskaera-lerrorako, indizea duen eremua ordena-lerroekin taulatik irakurriko da. Eskaera-data aldatzen denean, sistemak berak automatikoki berriro kalkulatuko du denormalizatutako data lerroan.

Abantailak

Zertarako da mekanismo hori guztia? DBMS klasikoetan, kontsultak berridatzi gabe, garatzaile batek edo DBA batek indizeak alda ditzakete, estatistikak zehaztu eta kontsulta-planifikatzaileari nola exekutatu behar dituen esan (eta HINTak DBMS komertzialetan bakarrik daude eskuragarri). Nahiz eta saiatzen diren, ezin izango dute artikuluko lehenengo kontsulta osatu O (sail kopurua) kontsultak aldatu edo abiarazleak gehitu gabe. Proposatutako eskeman, garapen-fasean ez duzu pentsatu behar datuak biltegiratzeko egituran eta zein agregazio erabili. Hori guztia erraz alda daiteke hegan, zuzenean martxan.

Praktikan honelakoa dirudi. Batzuek logika garatzen dute zuzenean eskuartean duten zereginean oinarrituta. Ez dute ulertzen algoritmoak eta haien konplexutasuna, ez exekuzio-planak, ez elkartze motak, ez beste osagai teknikorik. Pertsona hauek garatzaileak baino negozio analista gehiago dira. Ondoren, hori guztia proba edo funtzionamenduan sartzen da. Epe luzeko kontsulten erregistroa gaitzen du. Kontsulta luze bat detektatzen denean, beste pertsona batzuek (teknikoagoak - funtsean DBA) erabakitzen dute MATERIALIZED gaitzea tarteko funtzio batzuetan. Horrek grabaketa apur bat moteltzen du (transakzioan eremu gehigarri bat eguneratu behar baita). Hala ere, kontsulta hau nabarmen bizkortzen ez ezik, funtzio hau erabiltzen duten beste guztiak ere azkartzen dira. Aldi berean, zein funtzio gauzatu erabakitzea nahiko erraza da. Bi parametro nagusi: sarrera-balio posibleen kopurua (dagokion taulan zenbat erregistro egongo diren) eta beste funtzio batzuetan zenbat aldiz erabiltzen den.

analogs

DBMS komertzial modernoek antzeko mekanismoak dituzte: IKUSPEGI MATERIALIZATUA FAST REFRESH (Oracle) eta INDEXED VIEW (Microsoft SQL Server). PostgreSQL-n, MATERIALIZED VIEW ezin da transakzio batean eguneratu, eskaera eginda baizik (eta murrizketa oso zorrotzekin ere), beraz, ez dugu kontuan hartzen. Baina erabilera nabarmen mugatzen duten hainbat arazo dituzte.

Lehenik eta behin, materializazioa soilik gaitu dezakezu dagoeneko ohiko VIEW sortu baduzu. Bestela, sortu berri den ikuspegira sartzeko gainerako eskaerak berridatzi beharko dituzu materializazio hori erabiltzeko. Edo dena dagoen bezala utzi, baina gutxieneko eraginkorra izango da aurrez kalkulatutako zenbait datu baldin badaude, baina kontsulta askok ez dute beti erabiltzen, baizik eta berriro kalkulatzen dute.

Bigarrenik, murrizketa ugari dituzte:

Oracle

5.3.8.4 Freskatze azkarrari buruzko murrizketa orokorrak

Materializatutako ikuspegiaren definizio-kontsulta honela mugatuta dago:

  • Materializatutako ikuspegiak ez du errepikatzen ez diren esamoldeen erreferentziarik izan behar SYSDATE ROWNUM.
  • Materializatutako ikuspegiak ez du erreferentziarik izan behar RAW or LONG RAW datu motak.
  • Ezin du eduki a SELECT zerrenda azpikontsulta.
  • Ezin ditu funtzio analitikoak eduki (adibidez, RANK) SELECT klausula.
  • Ezin du erreferentzia bat zein den taula bat XMLIndex indizea definituta dago.
  • Ezin du eduki a MODEL klausula.
  • Ezin du eduki a HAVING azpikontsulta duen klausula.
  • Ezin ditu eduki dituzten kontsulta habiaratuak ANY, ALLEdo NOT EXISTS.
  • Ezin du eduki a [START WITH …] CONNECT BY klausula.
  • Ezin ditu hainbat xehetasun-taula eduki gune ezberdinetan.
  • ON COMMIT materializatutako bistak ezin dituzte urruneko xehetasun-taulak izan.
  • Habiaratutako materializatutako bistak batu edo agregatu bat izan behar dute.
  • Bateratze-ikuspegi materializatuak eta a-rekin bateratutako ikuspegi materializatuak GROUP BY klausulak ezin du hautatu indizean antolatutako taula batetik.

5.3.8.5 Freskatze bizkorrari buruzko murrizketak batuketak soilik dituzten ikuspegi materializatuetan

Ikuspegi materializatuetarako kontsultak batuketarekin soilik eta agregaturik gabe definitzeak murrizketa hauek ditu freskatze azkarrean:

  • Murrizketa guztiak Β«Freskatze azkarrari buruzko murrizketa orokorrak".
  • Ezin dute izan GROUP BY klausulak edo agregatuak.
  • Mahai guztien errenkadak FROM zerrendan agertu behar da SELECT kontsultaren zerrenda.
  • Materializatutako bista-erregistroak errenkadekin egon behar dute oinarrizko taula guztientzat FROM kontsultaren zerrenda.
  • Ezin duzu taula anitzetatik materializatutako ikuspegi azkar freskagarririk sortu, objektu-mota zutabe bat barne duten elkartze soilekin. SELECT adierazpen.

Gainera, aukeratzen duzun freskatze metodoa ez da eraginkorrena izango bada:

  • Definizio-kontsultak barne-juntura baten antzera jokatzen duen kanpo-juntura bat erabiltzen du. Definizio-kontsultak halako juntadura bat badu, kontuan hartu definizio-kontsulta berridaztea barne-juntura bat eduki dezan.
  • The SELECT Materializatutako ikuspegiaren zerrendak hainbat taulatako zutabeetako esamoldeak ditu.

5.3.8.6 Agregatuekin materializatutako ikuspegietan freskatze azkarreko murrizketak

Agregazio edo baturekin materializatutako ikuspegietarako kontsultak definitzeak murrizketa hauek ditu freskatze azkarrean:

Freskatze azkarra onartzen da bietarako ON COMMIT ON DEMAND ikuspegi materializatuak, hala ere, murrizketa hauek aplikatzen dira:

  • Ikuspegi materializatuko taula guztiek ikuspegi materializatuen erregistroak izan behar dituzte, eta ikuspegi materializatuen erregistroek:
    • Materializatutako ikuspegian erreferentziatutako taulako zutabe guztiak eduki.
    • Zehaztu honekin ROWID INCLUDING NEW VALUES.
    • Zehaztu SEQUENCE klausula taulak txertaketak/zuzeneko kargak, ezabatzeak eta eguneratzeak nahastea espero bada.

  • Bakarrik SUM, COUNT, AVG, STDDEV, VARIANCE, MIN MAX freskatze azkarra egiteko onartzen dira.
  • COUNT(*) zehaztu behar da.
  • Funtzio agregatuek adierazpenaren kanpoaldeko zati gisa bakarrik gertatu behar dute. Hau da, agregatuak, esaterako AVG(AVG(x)) or AVG(x)+ AVG(x) ez dira onartzen.
  • Agregatu bakoitzeko, esaterako AVG(expr), dagokiona COUNT(expr) presente egon behar du. Oraclek hori gomendatzen du SUM(expr) zehaztuko da.
  • If VARIANCE(expr) or STDDEV(expr) zehazten da, COUNT(expr) SUM(expr) zehaztu behar da. Oraclek hori gomendatzen du SUM(expr *expr) zehaztuko da.
  • The SELECT definizio-kontsultaren zutabea ezin da adierazpen konplexua izan oinarri-taula anitzetako zutabeekin. Honetarako konponbide posible bat materializatutako ikuspegi habiaratu bat erabiltzea da.
  • The SELECT zerrendak guztiak eduki behar ditu GROUP BY zutabeak.
  • Materializatutako ikuspegia ez da urruneko taula batean edo gehiagotan oinarritzen.
  • A erabiltzen baduzu CHAR Materializatutako ikuspegiaren erregistroko iragazki-zutabeetako datu-motak, gune nagusiaren karaktere-multzoak eta materializatutako ikuspegiak berdinak izan behar dute.
  • Materializatutako ikuspegiak honako hauetako bat badu, freskatze azkarra ohiko DML txertatzeetan eta karga zuzenetan soilik onartzen da.
    • Ikuspegi materializatuekin MIN or MAX agregatu
    • duten ikuspegi materializatuak SUM(expr) baina ez COUNT(expr)
    • Ikuspegi materializaturik gabe COUNT(*)

    Horrelako ikuspegi materializatu bati txertatzeko soilik deitzen zaio ikuspegi materializatua.

  • Ikuspegi materializatua MAX or MIN azkar freska daiteke DML adierazpenak ezabatu edo nahastu ondoren ez badu WHERE klausula.
    DML ezabatu edo nahastu ondoren gehienez/min freskatze azkarrak ez du txertatzeko soilik kasuaren portaera bera. Eragindako taldeen gehienezko/min balioak ezabatu eta berriro kalkulatzen ditu. Bere errendimenduaren eraginaren berri izan behar duzu.
  • Ikuspegi materializatuak izeneko ikuspegi edo azpikontsultekin FROM klausula azkar freskatu daiteke, baldin eta ikuspegiak guztiz batu badira. Zein ikuspegi bateratuko diren jakiteko, ikus Oracle Database SQL Language Erreferentzia.
  • Kanpoko elkartzerik ez badago, aukeraketa eta elkartze arbitrarioak izan ditzakezu WHERE klausula.
  • Kanpo-junturak dituzten agregazio-ikuspegi materializatuak azkar freska daitezke DML konbentzionalak eta karga zuzenen ondoren, baldin eta kanpoko taula soilik aldatu bada. Era berean, murriztapen esklusiboak egon behar dira barneko juntadura-taularen elkartze-zutabeetan. Kanpo-junturak badaude, juntagailu guztiak konektatu behar dira ANDs eta berdintasuna erabili behar du (=) operadorea.
  • Bista materializatuetarako CUBE, ROLLUP, taldekatze-multzoak edo horien kateatzea, murrizketa hauek aplikatzen dira:
    • The SELECT zerrendak taldekatze-bereiztzailea izan behar du, a izan daitekeena GROUPING_ID guztien funtzioa GROUP BY esapideak edo GROUPING funtzio bakoitzeko bat GROUP BY adierazpena. Adibidez, bada GROUP BY materializatutako ikuspegiaren klausula da "GROUP BY CUBE(a, b)", gero SELECT zerrendak izan behar du "GROUPING_ID(a, b)Β» edo Β«GROUPING(a) AND GROUPING(b)Β» materializatutako ikuspegia azkar freskagarria izan dadin.
    • GROUP BY ez luke taldekatze bikoizturik sortu behar. Adibidez, "GROUP BY a, ROLLUP(a, b)" ez da azkar freskagarria taldekatze bikoiztuak sortzen dituelako "(a), (a, b), AND (a)".

5.3.8.7 UNION ALL-ekin bista materializatuetan freskatze azkarreko murrizketak

Ikuspegi materializatuak UNION ALL ezarri operadorearen laguntza REFRESH FAST aukera, baldintza hauek betetzen badira:

  • Definizioko kontsultak izan behar du UNION ALL goi-mailako operadorea.

    The UNION ALL operadorea ezin da azpikontsulta batean txertatu, salbuespen batekin: The UNION ALL azpikontsulta batean egon daiteke FROM klausula, baldin eta definizio-kontsulta formakoa bada SELECT * FROM (ikusi edo azpikontsulta honekin UNION ALL) adibide honetan bezala:

    CREATE VIEW view_with_unionall AS (HAUTATU c.rowid crid, c.cust_id, 2 umarker bezeroetatik c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker bezeroetatik c WHERE c.cust_name = 'Jones'); SORTU IKUSPEGIA MATERIALIZATUA unionall_inside_view_mv FRESKATU AZKAR ESKATUAN HAUTATU EGINEZ * FROM view_with_unionall;

    Kontuan izan ikuspegia view_with_unionall freskatze azkarrerako baldintzak betetzen ditu.

  • Kontsulta-bloke bakoitza UNION ALL kontsultak agregatuekin edo materializatutako ikuspegi azkar freskagarri baten baldintzak bete behar ditu baturekin.

    Materializatutako ikuspegiaren erregistro egokiak sortu behar dira tauletan, dagokion materializatu azkar freskagarria den ikuspegi motarako behar den moduan.
    Kontuan izan Oracle Datu-baseak taula bakarreko ikuspegi materializatu baten kasu berezia ere onartzen duela, baldin eta batzeak soilik ROWID zutabean sartu da SELECT zerrendan eta materializatutako ikuspegien erregistroan. Hau ikuspegiaren definizio kontsultan erakusten da view_with_unionall.

  • The SELECT Kontsulta bakoitzaren zerrendak bat izan behar du UNION ALL markatzailea, eta UNION ALL zutabeak zenbakizko edo kate-balio konstante bereizia izan behar du bakoitzean UNION ALL adarra. Gainera, markatzailearen zutabeak posizio ordinal berean agertu behar du SELECT kontsulta-bloke bakoitzaren zerrenda. Ikusi "UNION ALL Markatzailea eta Kontsulten berridazketaΒ» buruzko informazio gehiago lortzeko UNION ALL markatzaileak.
  • Ezaugarri batzuk, hala nola kanpoko elkarketak, txertatzeko soilik agregatutako ikuspegi materializatuen kontsultak eta urruneko taulak ez dira onartzen materializatutako ikuspegiekin. UNION ALL. Kontuan izan, hala ere, errepliketan erabiltzen diren ikuspegi materializatuak, batuketak edo agregatuak ez dituztenak, azkar freskatu daitezkeela. UNION ALL edo urruneko mahaiak erabiltzen dira.
  • Bateragarritasun-hasierako parametroa 9.2.0 edo handiagoan ezarri behar da ikuspegi materializatu azkar freskagarria sortzeko. UNION ALL.

Ez ditut Oracle zaleak iraindu nahi, baina haien murrizketen zerrenda ikusita, badirudi mekanismo hau ez dela kasu orokorrean idatzia, nolabaiteko eredu bat erabiliz, baizik eta milaka indiarrek, non denek aukera eman baitzuten. idatzi bere adarra, eta bakoitzak ahal zuena egin zuen eta egin zuen. Mekanismo hau benetako logikarako erabiltzea meatze-eremu batean ibiltzea bezalakoa da. Edonoiz lor dezakezu meategi bat begi-bistakoa ez den murrizketa bat sakatuz. Nola funtzionatzen duen ere aparteko galdera bat da, baina artikulu honen esparrutik kanpo dago.

Microsoft SQL Server

Baldintza gehigarriak

SET aukerez eta funtzio deterministikoaren eskakizunez gain, baldintza hauek bete behar dira:

  • Exekutatzen duen erabiltzailea CREATE INDEX ikuspegiaren jabea izan behar du.
  • Indizea sortzen duzunean, IGNORE_DUP_KEY aukera OFF moduan ezarri behar da (ezarpen lehenetsia).
  • Taulei bi ataleko izenekin erreferentzia egin behar zaie, eskema.taula izena ikuspegiaren definizioan.
  • Erabiltzaileak definitutako funtzioak bista erabiliz sortu behar dira WITH SCHEMABINDING aukera.
  • Ikuspegian erreferentziatutako erabiltzaileak definitutako edozein funtzio bi ataleko izenekin erreferentzia egin behar da. ..
  • Erabiltzaileak definitutako funtzio baten datuetarako sarbidea izan behar du NO SQL, eta kanpoko sarbidearen jabetza izan behar du NO.
  • Common Language Runtime (CLR) funtzioak bistaren hautapen-zerrendan ager daitezke, baina ezin dira multzokaturiko indize-gakoaren definizioaren parte izan. CLR funtzioak ezin dira agertu ikuspegiko WHERE klausulan edo ON klausulan JOIN eragiketa baten ikuspegian.
  • Ikuspegiaren definizioan erabiltzen diren CLR funtzioek eta CLR erabiltzaileak definitutako moten metodoek propietateak ezarri behar dituzte ondoko taulan erakusten den moduan.

    Jabetza
    Ohar

    DETERMINISTIKOA = EGIA
    Microsoft .NET Framework metodoaren atributu gisa esplizituki deklaratu behar da.

    ZEHATZA = EGIA
    .NET Framework metodoaren atributu gisa esplizituki deklaratu behar da.

    DATU SARBIDEA = SQL EZ
    DataAccess atributua DataAccessKind.None eta SystemDataAccess atributua SystemDataAccessKind.None ezarriz zehazten da.

    KANPO SARBIDEA = EZ
    Propietate honek NO du lehenetsia CLR errutinetarako.

  • Ikuspegia erabiliz sortu behar da WITH SCHEMABINDING aukera.
  • Ikuspegiak ikuspegiaren datu-base berean dauden oinarrizko taulak soilik erreferentziatu behar ditu. Ikuspegiak ezin ditu beste ikuspegi batzuk aipatu.
  • Ikuspegiaren definizioko SELECT instrukzioak ez ditu Transact-SQL elementu hauek izan behar:

    COUNT
    ROWSET funtzioak (OPENDATASOURCE, OPENQUERY, OPENROWSET, ETA OPENXML)
    OUTER batu(LEFT, RIGHTEdo FULL)

    Taula eratorria (a zehaztuz definitua SELECT adierazpenean FROM klausula)
    Norberak elkartzea
    Erabiliz zutabeak zehaztea SELECT * or SELECT <table_name>.*

    DISTINCT
    STDEV, STDEVP, VAR, VARPEdo AVG
    Taularen adierazpen arrunta (CTE)

    float1, testu, ntestua, irudia, XMLEdo fitxategi-korrontea zutabeak
    Azpikontsulta
    OVER klausula, sailkapen edo leiho agregatuaren funtzioak barne hartzen dituena

    Testu osoko predikatuak (CONTAINS, FREETEXT)
    SUM adierazpen baliogabe bati erreferentzia egiten dion funtzioa
    ORDER BY

    CLR erabiltzaileak definitutako agregazio-funtzioa
    TOP
    CUBE, ROLLUPEdo GROUPING SETS operadoreei

    MIN, MAX
    UNION, EXCEPTEdo INTERSECT operadoreei
    TABLESAMPLE

    Taularen aldagaiak
    OUTER APPLY or CROSS APPLY
    PIVOT, UNPIVOT

    Zutabe multzo urriak
    Lineako (TVF) edo adierazpen anitzeko taula-baliodun funtzioak (MSTVF)
    OFFSET

    CHECKSUM_AGG

    1 Ikuspegi indexatuak eduki dezake float zutabeak; hala ere, zutabe horiek ezin dira sartu indize-gako multzokatuan.

  • If GROUP BY badago, VIEW definizioak eduki behar du COUNT_BIG(*) eta ez du eduki behar HAVING. Hauek GROUP BY murrizketak indexatutako ikuspegiaren definizioari soilik aplikatzen zaizkio. Kontsulta batek bere exekuzio-planean indexatutako ikuspegi bat erabil dezake, hauek betetzen ez baditu ere GROUP BY murrizketak.
  • Ikuspegiaren definizioak bat badu GROUP BY klausula, clustered indize esklusiboaren gakoak atalean zehaztutako zutabeei soilik erreferentzia egin diezaieke GROUP BY klausula.

Hemen argi dago indioek ez zutela parte hartu, eskemaren arabera egitea erabaki baitzuten "gutxi egingo dugu, baina ondo". Hau da, meategi gehiago dituzte zelaian, baina haien kokapena gardenagoa da. Etsigarriena muga hau da:

Ikuspegiak ikuspegiaren datu-base berean dauden oinarrizko taulak soilik erreferentziatu behar ditu. Ikuspegiak ezin ditu beste ikuspegi batzuk aipatu.

Gure terminologian, horrek esan nahi du funtzio batek ezin duela beste funtzio materializatu batean sartu. Horrek ideologia guztia murrizten du.
Gainera, muga honek (eta testuan gehiago) asko murrizten ditu erabilera kasuak:

Ikuspegiaren definizioko SELECT instrukzioak ez ditu Transact-SQL elementu hauek izan behar:

COUNT
ROWSET funtzioak (OPENDATASOURCE, OPENQUERY, OPENROWSET, ETA OPENXML)
OUTER batu(LEFT, RIGHTEdo FULL)

Taula eratorria (a zehaztuz definitua SELECT adierazpenean FROM klausula)
Norberak elkartzea
Erabiliz zutabeak zehaztea SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARPEdo AVG
Taularen adierazpen arrunta (CTE)

float1, testu, ntestua, irudia, XMLEdo fitxategi-korrontea zutabeak
Azpikontsulta
OVER klausula, sailkapen edo leiho agregatuaren funtzioak barne hartzen dituena

Testu osoko predikatuak (CONTAINS, FREETEXT)
SUM adierazpen baliogabe bati erreferentzia egiten dion funtzioa
ORDER BY

CLR erabiltzaileak definitutako agregazio-funtzioa
TOP
CUBE, ROLLUPEdo GROUPING SETS operadoreei

MIN, MAX
UNION, EXCEPTEdo INTERSECT operadoreei
TABLESAMPLE

Taularen aldagaiak
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Zutabe multzo urriak
Lineako (TVF) edo adierazpen anitzeko taula-baliodun funtzioak (MSTVF)
OFFSET

CHECKSUM_AGG

OUTTER JOINS, UNION, ORDER BY eta beste batzuk debekatuta daude. Errazagoa izan zitekeen zer erabil zitekeen zehaztea erabili ezin zena baino. Zerrenda askoz txikiagoa izango litzateke ziurrenik.

Laburbilduz: LGPL teknologiako (logiko bat, ez tekniko bat izan ezik) DBMS guztietan (kontuan izan dezagun komertziala) murrizketa multzo handi bat eta bat ere ez. Hala ere, esan behar da mekanismo hau erlazio-logikan inplementatzea deskribatutako logika funtzionalean baino zailagoa dela.

Inplementazioa

Nola dabil? PostgreSQL "makina birtual" gisa erabiltzen da. Barruan algoritmo konplexu bat dago kontsultak eraikitzen dituena. Hemen iturria. Eta ez dago heuristika multzo handi bat ifs mordo batekin. Beraz, ikasteko hilabete pare bat baduzu, arkitektura ulertzen saia zaitezke.

Eraginkortasunez funtzionatzen du? Nahiko eraginkorra. Zoritxarrez, hori frogatzea zaila da. Bakarrik esan dezaket aplikazio handietan dauden milaka kontsulta kontuan hartzen badituzu, batez beste garatzaile on batenak baino eraginkorragoak direla. SQL programatzaile bikain batek edozein kontsulta idatz dezake modu eraginkorragoan, baina mila kontsultarekin ez du horretarako motibaziorik edo denborarik izango. Orain eraginkortasunaren froga gisa aipa dezakedan gauza bakarra da hainbat proiektu lanean ari direla DBMS honetan eraikitako plataforman. ERP sistemak, milaka MATERIALIZATU funtzio ezberdin dituztenak, milaka erabiltzaile eta terabyte-ko datu-baseekin ehunka milioi erregistro dituzten bi prozesadore arrunteko zerbitzari batean exekutatzen direnak. Hala ere, edonork egiaztatu/ereztatu dezake eraginkortasuna deskargatuz plataforma eta PostgreSQL, piztuz SQL kontsultak erregistratzen eta bertan logika eta datuak aldatzen saiatzen.

Hurrengo artikuluetan, funtzioetan murrizketak ezarri, aldaketa-saioekin lan egin eta askoz gehiago nola ezar ditzakezun ere hitz egingo dut.

Iturria: www.habr.com

Gehitu iruzkin berria