Mae cydbwyso yn ysgrifennu ac yn darllen yn y gronfa ddata

Mae cydbwyso yn ysgrifennu ac yn darllen yn y gronfa ddata
Yn y blaenorol Erthygl Disgrifiais y cysyniad a gweithrediad cronfa ddata a adeiladwyd ar sail swyddogaethau, yn hytrach na thablau a meysydd fel mewn cronfeydd data perthynol. Darparodd lawer o enghreifftiau yn dangos manteision y dull hwn o weithredu dros yr un clasurol. Roedd llawer yn teimlo nad oeddent yn ddigon argyhoeddiadol.

Yn yr erthygl hon, byddaf yn dangos sut mae'r cysyniad hwn yn caniatáu ichi gydbwyso ysgrifennu a darllen i'r gronfa ddata yn gyflym ac yn gyfleus heb unrhyw newid yn y rhesymeg weithredu. Ceisiwyd gweithredu swyddogaethau tebyg mewn DBMSs masnachol modern (yn arbennig, Oracle a Microsoft SQL Server). Ar ddiwedd yr erthygl byddaf yn dangos na wnaeth yr hyn a wnaethant, i'w roi'n ysgafn, weithio allan yn dda iawn.

Disgrifiad

Fel o'r blaen, er mwyn deall yn well byddaf yn dechrau'r disgrifiad gydag enghreifftiau. Gadewch i ni ddweud bod angen i ni weithredu rhesymeg a fydd yn dychwelyd rhestr o adrannau gyda nifer y gweithwyr ynddynt a chyfanswm eu cyflog.

Mewn cronfa ddata swyddogaethol byddai'n edrych fel hyn:

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

Bydd cymhlethdod gweithredu'r ymholiad hwn mewn unrhyw DBMS yn cyfateb i O (nifer y gweithwyr)oherwydd mae'r cyfrifiad hwn yn gofyn am sganio'r tabl cyfan o weithwyr ac yna eu grwpio fesul adran. Bydd hefyd rhai atodiadau bach (credwn fod llawer mwy o weithwyr nag adrannau) yn dibynnu ar y cynllun a ddewiswyd O (nifer log y gweithwyr) neu O (nifer o adrannau) ar gyfer grwpio ac ati.

Mae'n amlwg y gall y gorbenion cyflawni fod yn wahanol mewn gwahanol DBMSs, ond ni fydd y cymhlethdod yn newid mewn unrhyw ffordd.

Yn y gweithrediad arfaethedig, bydd y DBMS swyddogaethol yn cynhyrchu un subquery a fydd yn cyfrifo'r gwerthoedd gofynnol ar gyfer yr adran, ac yna'n gwneud YMUNO â thabl yr adran i gael yr enw. Fodd bynnag, ar gyfer pob swyddogaeth, wrth ddatgan, mae'n bosibl gosod marciwr MATERIALIZED arbennig. Bydd y system yn creu maes cyfatebol yn awtomatig ar gyfer pob swyddogaeth o'r fath. Wrth newid gwerth swyddogaeth, bydd gwerth y maes hefyd yn newid yn yr un trafodiad. Wrth gyrchu'r swyddogaeth hon, bydd y maes a raggyfrifwyd yn cael ei gyrchu.

Yn benodol, os ydych chi'n gosod MATERIALIZED ar gyfer swyddogaethau cyfrif Gweithwyr и cyflogSwm, yna bydd dau faes yn cael eu hychwanegu at y tabl gyda'r rhestr o adrannau, a fydd yn storio nifer y gweithwyr a chyfanswm eu cyflog. Pryd bynnag y bydd newid mewn gweithwyr, eu cyflogau neu gysylltiadau adrannol, bydd y system yn newid gwerthoedd y meysydd hyn yn awtomatig. Bydd yr ymholiad uchod yn cyrchu'r meysydd hyn yn uniongyrchol a bydd yn cael ei weithredu ynddynt O (nifer o adrannau).

Beth yw'r cyfyngiadau? Dim ond un peth: mae'n rhaid bod gan swyddogaeth o'r fath nifer gyfyngedig o werthoedd mewnbwn y mae ei werth wedi'i ddiffinio ar ei gyfer. Fel arall, bydd yn amhosibl adeiladu tabl sy'n storio ei holl werthoedd, gan na all fod tabl gyda nifer anfeidrol o resi.

Enghraifft:

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

Mae'r ffwythiant hwn wedi'i ddiffinio ar gyfer nifer anfeidrol o werthoedd N (er enghraifft, mae unrhyw werth negyddol yn addas). Felly, ni allwch roi MATERIALIZED arno. Felly mae hwn yn gyfyngiad rhesymegol, nid yn un technegol (hynny yw, nid oherwydd na allem ei weithredu). Fel arall, nid oes unrhyw gyfyngiadau. Gallwch ddefnyddio grwpiau, didoli, AND a OR, PARTITION, recursion, ac ati.

Er enghraifft, ym mhroblem 2.2 yn yr erthygl flaenorol, gallwch chi roi MATERIALIZED ar y ddwy swyddogaeth:

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;

Bydd y system ei hun yn creu un tabl gydag allweddi math Cwsmeriaid, Dewisiwch eich eitem и CYFRIFOL, yn ychwanegu dau faes ato a bydd yn diweddaru'r gwerthoedd maes ynddynt gydag unrhyw newidiadau. Pan wneir galwadau pellach i'r swyddogaethau hyn, ni fyddant yn cael eu cyfrifo, ond yn hytrach bydd y gwerthoedd yn cael eu darllen o'r meysydd cyfatebol.

Gan ddefnyddio'r mecanwaith hwn, gallwch, er enghraifft, gael gwared ar recursions (CTE) mewn ymholiadau. Yn benodol, ystyriwch grwpiau sy’n ffurfio coeden gan ddefnyddio’r berthynas plentyn/rhiant (mae gan bob grŵp gysylltiad â’i riant):

parent = DATA Group (Group);

Mewn cronfa ddata swyddogaethol, gellir pennu rhesymeg dychwelyd fel a ganlyn:

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;

Ers ar gyfer y swyddogaeth yn Rhiant wedi'i farcio MATERIALIZED, yna bydd tabl gyda dau allwedd (grwpiau) yn cael ei greu ar ei gyfer, lle mae'r maes yn Rhiant bydd yn wir dim ond os yw'r allwedd gyntaf yn blentyn i'r ail. Bydd nifer y cofnodion yn y tabl hwn yn hafal i nifer y grwpiau wedi'i luosi â dyfnder cyfartalog y goeden. Os oes angen, er enghraifft, i gyfrif nifer y disgynyddion o grŵp penodol, gallwch ddefnyddio'r swyddogaeth hon:

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

Ni fydd CTE yn yr ymholiad SQL. Yn lle hynny bydd GRŴP syml GAN.

Gan ddefnyddio'r mecanwaith hwn, gallwch hefyd ddadnormaleiddio'r gronfa ddata yn hawdd os oes angen:

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

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

Wrth alw swyddogaeth dyddiad ar gyfer y llinell archebu, bydd y maes y mae mynegai ar ei gyfer yn cael ei ddarllen o'r tabl gyda llinellau trefn. Pan fydd dyddiad y gorchymyn yn newid, bydd y system ei hun yn ailgyfrifo'r dyddiad dadnormaleiddio yn y llinell yn awtomatig.

Manteision

Beth yw pwrpas yr holl fecanwaith hwn? Mewn DBMSs clasurol, heb ailysgrifennu ymholiadau, ni all datblygwr neu DBA ond newid mynegeion, pennu ystadegau a dweud wrth y cynlluniwr ymholiad sut i'w gweithredu (a dim ond mewn DBMS masnachol y mae HINTs ar gael). Ni waeth pa mor galed y maent yn ceisio, ni fyddant yn gallu cwblhau'r ymholiad cyntaf yn yr erthygl yn O (nifer o adrannau) heb newid ymholiadau nac ychwanegu sbardunau. Yn y cynllun arfaethedig, ar y cam datblygu nid oes rhaid i chi feddwl am y strwythur storio data a pha agregau i'w defnyddio. Gellir newid hyn i gyd yn hawdd ar y hedfan, yn uniongyrchol ar waith.

Yn ymarferol mae'n edrych fel hyn. Mae rhai pobl yn datblygu rhesymeg yn uniongyrchol yn seiliedig ar y dasg dan sylw. Nid ydynt yn deall algorithmau a'u cymhlethdod, cynlluniau gweithredu, mathau o ymuniadau, nac unrhyw gydran dechnegol arall. Mae'r bobl hyn yn fwy o ddadansoddwyr busnes na datblygwyr. Yna, mae hyn i gyd yn mynd i mewn i brofi neu weithredu. Galluogi logio ymholiadau hirsefydlog. Pan ganfyddir ymholiad hir, yna mae pobl eraill (mwy technegol - yn y bôn DBA) yn penderfynu galluogi MATERIALIZED ar rai swyddogaeth ganolraddol. Mae hyn yn arafu'r recordiad ychydig (gan fod angen diweddaru maes ychwanegol yn y trafodiad). Fodd bynnag, nid yn unig yr ymholiad hwn yn cael ei gyflymu'n sylweddol, ond hefyd yr holl rai eraill sy'n defnyddio'r swyddogaeth hon. Ar yr un pryd, mae penderfynu pa swyddogaeth i'w gwireddu yn gymharol hawdd. Dau brif baramedr: nifer y gwerthoedd mewnbwn posibl (dyma faint o gofnodion fydd yn y tabl cyfatebol), a pha mor aml y caiff ei ddefnyddio mewn swyddogaethau eraill.

Analogs

Mae gan DBMSs masnachol modern fecanweithiau tebyg: VIEW MATERIALIZED gyda FAST REFRESH (Oracle) a VIEW INDEXED (Microsoft SQL Server). Yn PostgreSQL, ni ellir diweddaru VIEW MATERIALIZED mewn trafodiad, ond dim ond ar gais (a hyd yn oed gyda chyfyngiadau llym iawn), felly nid ydym yn ei ystyried. Ond mae ganddynt nifer o broblemau sy'n cyfyngu'n sylweddol ar eu defnydd.

Yn gyntaf, dim ond os ydych chi eisoes wedi creu VIEW rheolaidd y gallwch chi alluogi gwireddu. Fel arall, bydd yn rhaid i chi ailysgrifennu'r ceisiadau sy'n weddill i gael mynediad i'r olwg sydd newydd ei greu i ddefnyddio'r gwireddu hwn. Neu gadewch bopeth fel y mae, ond bydd yn aneffeithiol o leiaf os oes data penodol eisoes wedi'i gyfrifo, ond nid yw llawer o ymholiadau bob amser yn ei ddefnyddio, ond yn ei ailgyfrifo.

Yn ail, mae ganddynt nifer fawr o gyfyngiadau:

Oracle

5.3.8.4 Cyfyngiadau Cyffredinol ar Adnewyddu Cyflym

Mae’r ymholiad diffiniol o’r olygfa sydd wedi’i gwireddu wedi’i gyfyngu fel a ganlyn:

  • Ni ddylai'r olygfa berthnasol gynnwys cyfeiriadau at ymadroddion nad ydynt yn ailadrodd megis SYSDATE ac ROWNUM.
  • Ni ddylai'r olygfa berthnasol gynnwys cyfeiriadau at RAW or LONG RAW mathau o ddata.
  • Ni all gynnwys a SELECT subquery rhestr.
  • Ni all gynnwys swyddogaethau dadansoddol (er enghraifft, RANK) yn y SELECT cymal.
  • Ni all gyfeirio at dabl y mae a XMLIndex mynegai yn cael ei ddiffinio.
  • Ni all gynnwys a MODEL cymal.
  • Ni all gynnwys a HAVING cymal gyda subquery.
  • Ni all gynnwys ymholiadau nythu sydd wedi ANY, ALL, neu NOT EXISTS.
  • Ni all gynnwys a [START WITH …] CONNECT BY cymal.
  • Ni all gynnwys tablau manylder lluosog mewn gwahanol safleoedd.
  • ON COMMIT ni all golygfeydd wedi'u gwireddu gael tablau manylion o bell.
  • Rhaid i olygfeydd sylweddedig nythu gael uniad neu agreg.
  • Golygfeydd uno materol a golygfeydd cyfanredol wedi'u gwireddu gydag a GROUP BY ni all cymal ddewis o dabl wedi'i drefnu gan fynegai.

5.3.8.5 Cyfyngiadau ar Adnewyddu Cyflym ar Golygfeydd Materol gydag Ymuno yn Unig

Diffinio ymholiadau ar gyfer safbwyntiau wedi'u gwireddu gydag uniadau yn unig ac nid oes gan unrhyw agregau y cyfyngiadau canlynol ar adnewyddu cyflym:

  • Pob cyfyngiad o «Cyfyngiadau Cyffredinol ar Adnewyddu Cyflym".
  • Ni allant gael GROUP BY cymalau neu agregau.
  • Rowids o'r holl fyrddau yn y FROM rhaid i'r rhestr ymddangos yn y SELECT rhestr o'r ymholiad.
  • Rhaid i logiau gweld materol fodoli gyda rowids ar gyfer yr holl dablau sylfaen yn y FROM rhestr o'r ymholiad.
  • Ni allwch greu golygfa sylweddol y gellir ei hadnewyddu'n gyflym o sawl tabl gydag uniadau syml sy'n cynnwys colofn math gwrthrych yn y SELECT datganiad.

Hefyd, ni fydd y dull adnewyddu a ddewiswch yn fwyaf effeithlon os:

  • Mae'r ymholiad diffiniol yn defnyddio uniad allanol sy'n ymddwyn fel uniad mewnol. Os yw'r ymholiad diffiniol yn cynnwys uniad o'r fath, ystyriwch ailysgrifennu'r ymholiad diffinio i gynnwys uniad mewnol.
  • Mae adroddiadau SELECT mae rhestr o'r wedd wedi'i gwireddu yn cynnwys mynegiadau ar golofnau o dablau lluosog.

5.3.8.6 Cyfyngiadau ar Adnewyddu Cyflym ar Golygfeydd Materol gydag Agregau

Mae’r cyfyngiadau canlynol ar adnewyddu cyflym wrth ddiffinio ymholiadau ar gyfer safbwyntiau wedi’u gwireddu gydag agregau neu gyfuniadau:

Cefnogir adnewyddu cyflym ar gyfer y ddau ON COMMIT ac ON DEMAND safbwyntiau wedi’u gwireddu, ond mae’r cyfyngiadau canlynol yn berthnasol:

  • Rhaid i bob bwrdd yn y golygfa wedi'i gwireddu fod â logiau gweld wedi'u gwireddu, a rhaid i'r logiau gweld wedi'u gwireddu:
    • Cynhwyswch yr holl golofnau o'r tabl y cyfeirir ato yn y golwg wedi'i wireddu.
    • Nodwch gyda ROWID ac INCLUDING NEW VALUES.
    • Nodwch y SEQUENCE cymal os disgwylir i'r tabl gynnwys cymysgedd o fewnosodiadau/llwythi uniongyrchol, dileadau, a diweddariadau.

  • Dim ond SUM, COUNT, AVG, STDDEV, VARIANCE, MIN ac MAX yn cael eu cefnogi ar gyfer adnewyddu cyflym.
  • COUNT(*) rhaid nodi.
  • Rhaid i ffwythiannau cyfanredol ddigwydd fel rhan fwyaf allanol y mynegiad yn unig. Hynny yw, agregau megis AVG(AVG(x)) or AVG(x)+ AVG(x) ni chaniateir.
  • Ar gyfer pob agreg megis AVG(expr), y cyfatebol COUNT(expr) rhaid bod yn bresennol. Mae Oracle yn argymell hynny SUM(expr) cael ei nodi.
  • If VARIANCE(expr) or STDDEV(expr) wedi'i nodi, COUNT(expr) ac SUM(expr) rhaid nodi. Mae Oracle yn argymell hynny SUM(expr *expr) cael ei nodi.
  • Mae adroddiadau SELECT ni all colofn yn yr ymholiad diffiniol fod yn fynegiad cymhleth gyda cholofnau o dablau sylfaen lluosog. Ateb posibl i hyn yw defnyddio golygfa wereiddiedig nythog.
  • Mae adroddiadau SELECT rhaid i'r rhestr gynnwys y cyfan GROUP BY colofnau.
  • Nid yw'r olygfa wedi'i gwireddu yn seiliedig ar un neu fwy o dablau anghysbell.
  • Os ydych chi'n defnyddio a CHAR math o ddata yng ngholofnau hidlydd log gweld wedi'i wireddu, rhaid i setiau nodau'r prif safle a'r olygfa wedi'i gwireddu fod yr un peth.
  • Os oes gan y golygfa wedi'i gwireddu un o'r canlynol, yna dim ond ar fewnosodiadau DML confensiynol a llwythi uniongyrchol y cefnogir adnewyddu cyflym.
    • Golygfeydd materol gyda MIN or MAX agregau
    • Golygfeydd materol sydd wedi SUM(expr) ond na COUNT(expr)
    • Golygfeydd materol heb COUNT(*)

    Gelwir golygfa o'r fath wedi'i gwireddu yn olygfa wedi'i gwireddu mewnosod yn unig.

  • Golygfa wedi'i gwireddu gyda MAX or MIN gellir ei adnewyddu'n gyflym ar ôl dileu neu ddatganiadau DML cymysg os nad oes ganddo a WHERE cymal.
    Nid oes gan yr adnewyddiad cyflym mwyaf/munud ar ôl dileu neu DML cymysg yr un ymddygiad â'r cas mewnosod yn unig. Mae'n dileu ac yn ailgyfrifo'r gwerthoedd uchaf/min ar gyfer y grwpiau yr effeithir arnynt. Mae angen i chi fod yn ymwybodol o'i effaith perfformiad.
  • Golygfeydd materol gyda golygfeydd neu subqueries a enwir yn y FROM gellir adnewyddu'r cymal yn gyflym ar yr amod y gellir cyfuno'r safbwyntiau'n llwyr. Am wybodaeth ar ba olygfeydd fydd yn uno, gweler Cyfeirnod Iaith SQL Cronfa Ddata Oracle.
  • Os nad oes unrhyw uniadau allanol, efallai y bydd gennych ddetholiadau mympwyol ac yn ymuno yn y WHERE cymal.
  • Gellir adnewyddu golygfeydd cyfanredol materol gydag uniadau allanol yn gyflym ar ôl DML confensiynol a llwythi uniongyrchol, ar yr amod mai dim ond y bwrdd allanol sydd wedi'i addasu. Hefyd, rhaid i gyfyngiadau unigryw fodoli ar golofnau uno'r tabl uno mewnol. Os oes uniadau allanol, rhaid cysylltu pob uniad ANDs a rhaid iddo ddefnyddio'r cydraddoldeb (=) gweithredwr.
  • Ar gyfer golygfeydd materol gyda CUBE, ROLLUP, grwpio setiau, neu eu cydgadwynu, mae'r cyfyngiadau canlynol yn berthnasol:
    • Mae adroddiadau SELECT dylai'r rhestr gynnwys gwahaniaethwr grwpio a all fod yn a GROUPING_ID swyddogaeth ar y cyfan GROUP BY ymadroddion neu GROUPING swyddogaethau un ar gyfer pob un GROUP BY mynegiant. Er enghraifft, os yw'r GROUP BY cymal o'r farn wedi'i gwireddu yw "GROUP BY CUBE(a, b)", yna y SELECT dylai'r rhestr gynnwys naill ai "GROUPING_ID(a, b)»Neu«GROUPING(a) AND GROUPING(b)» i'r olygfa wedi'i gwireddu fod yn adnewyddadwy'n gyflym.
    • GROUP BY ni ddylai arwain at unrhyw grwpiau dyblyg. Er enghraifft, "GROUP BY a, ROLLUP(a, b)" dim modd ei adnewyddu'n gyflym oherwydd mae'n arwain at grwpiau dyblyg "(a), (a, b), AND (a)".

5.3.8.7 Cyfyngiadau ar Adnewyddu Cyflym ar Safbwyntiau Materol gydag UNDEB PAWB

Golygfeydd materol gyda'r UNION ALL gweithredydd set cefnogi'r REFRESH FAST opsiwn os bodlonir yr amodau canlynol:

  • Rhaid bod gan yr ymholiad diffiniol y UNION ALL gweithredwr ar y lefel uchaf.

    Mae adroddiadau UNION ALL Ni all gweithredwr gael ei fewnosod y tu mewn i subquery, gydag un eithriad: The UNION ALL gall fod mewn subquery yn y FROM cymal ar yr amod bod yr ymholiad diffiniol o'r ffurf SELECT * FROM (gweld neu subquery gyda UNION ALL) fel yn yr enghraifft ganlynol:

    CREATE VIEW view_with_unionall AS
    (SELECT c.rowid crid, c.cust_id, 2 umarker
     GAN gwsmeriaid c WHERE c.cust_last_name = 'Smith'
     UNDEB PAWB
     SELECT c.rowid crid, c.cust_id, 3 umarker
     GAN gwsmeriaid c WHERE c.cust_last_name = 'Jones');
    
    CREATE MATERIALIZED VIEW unionall_inside_view_mv
    DIWYGIO YN GYFLYM AR GALW FEL
    SELECT * O view_with_unionall;
    

    Sylwch fod yr olygfa view_with_unionall yn bodloni'r gofynion ar gyfer adnewyddu cyflym.

  • Mae pob bloc ymholiad yn y UNION ALL rhaid i'r ymholiad fodloni gofynion golygfa wedi'i gwireddu'n gyflym y gellir ei hadnewyddu gydag agregau neu olygfa wedi'i gwireddu'n gyflym y gellir ei hadnewyddu gydag uniadau.

    Rhaid creu'r boncyffion golygfa sylweddol priodol ar y byrddau yn ôl yr angen ar gyfer y math cyfatebol o olygfa wedi'i gwireddu'n gyflym y gellir ei hadnewyddu.
    Sylwch fod Cronfa Ddata Oracle hefyd yn caniatáu achos arbennig o weld un tabl wedi'i wireddu gydag uniadau dim ond ar yr amod ROWID colofn wedi ei gynnwys yn y SELECT rhestr ac yn y log gweld wedi'i wireddu. Dangosir hyn yn yr ymholiad diffiniol o'r olygfa view_with_unionall.

  • Mae adroddiadau SELECT rhaid i restr o bob ymholiad gynnwys a UNION ALL marciwr, a'r UNION ALL rhaid i golofn fod â gwerth rhifol cyson neu llinynnol penodol ym mhob un UNION ALL cangen. Ymhellach, rhaid i'r golofn marcio ymddangos yn yr un sefyllfa drefnol yn y SELECT rhestr o bob bloc ymholiad. Gweler "UNDEB PAWB Marciwr ac Ymholiad Ailysgrifennu» i gael rhagor o wybodaeth am UNION ALL marcwyr.
  • Nid yw rhai nodweddion megis uniadau allanol, ymholiadau golwg cyfanredol mewnosod yn unig a thablau o bell yn cael eu cefnogi ar gyfer golygfeydd wedi'u gwireddu gyda UNION ALL. Sylwch, fodd bynnag, y gellir adnewyddu'n gyflym y golygfeydd a ddefnyddir wrth ddyblygu, nad ydynt yn cynnwys uniadau neu agregau, pan UNION ALL neu dablau o bell yn cael eu defnyddio.
  • Rhaid gosod y paramedr cychwyn cydnawsedd i 9.2.0 neu uwch er mwyn creu golygfa wedi'i gwireddu'n gyflym y gellir ei hadnewyddu gyda UNION ALL.

Nid wyf am dramgwyddo cefnogwyr Oracle, ond a barnu yn ôl eu rhestr o gyfyngiadau, mae'n ymddangos bod y mecanwaith hwn wedi'i ysgrifennu nid yn yr achos cyffredinol, gan ddefnyddio rhyw fath o fodel, ond gan filoedd o Indiaid, lle rhoddwyd cyfle i bawb. ysgrifennu eu cangen eu hunain, a phob un ohonynt a wnaeth yr hyn a allai, ac a wnaeth. Mae defnyddio'r mecanwaith hwn ar gyfer rhesymeg go iawn yn debyg i gerdded trwy faes mwyngloddio. Gallwch gael pwll ar unrhyw adeg drwy daro un o'r cyfyngiadau nad ydynt yn amlwg. Mae sut mae'n gweithio hefyd yn gwestiwn ar wahân, ond mae y tu hwnt i gwmpas yr erthygl hon.

Microsoft SQL Gweinyddwr

Gofynion Ychwanegol

Yn ogystal â'r opsiynau SET a gofynion swyddogaeth penderfyniaethol, rhaid bodloni'r gofynion canlynol:

  • Y defnyddiwr sy'n gweithredu CREATE INDEX rhaid iddo fod yn berchennog yr olygfa.
  • Pan fyddwch chi'n creu'r mynegai, mae'r IGNORE_DUP_KEY rhaid gosod yr opsiwn i OFF (y gosodiad diofyn).
  • Rhaid i dablau gael eu cyfeirio gan enwau dwy ran, sgema.enw bwrdd yn y diffiniad golygfa.
  • Rhaid creu swyddogaethau a ddiffinnir gan ddefnyddwyr y cyfeirir atynt yn yr olwg trwy ddefnyddio'r WITH SCHEMABINDING opsiwn.
  • Rhaid i unrhyw swyddogaethau a ddiffinnir gan ddefnyddiwr y cyfeirir atynt yn yr olwg gael eu cyfeirio gan enwau dwy ran, ..
  • Rhaid i eiddo mynediad data swyddogaeth a ddiffinnir gan y defnyddiwr fod NO SQL, a rhaid i eiddo mynediad allanol fod NO.
  • Gall swyddogaethau amser rhedeg iaith gyffredin (CLR) ymddangos yn rhestr ddethol y wedd, ond ni allant fod yn rhan o ddiffiniad yr allwedd mynegai clystyrog. Ni all ffwythiannau CLR ymddangos yng nghymal LLE o'r golwg na chymal YMLAEN gweithrediad JOIN yn yr olwg.
  • Rhaid i swyddogaethau CLR a dulliau o fathau CLR a ddiffinnir gan ddefnyddwyr a ddefnyddir yn y diffiniad golygfa gael y priodweddau a osodwyd fel y dangosir yn y tabl canlynol.

    Eiddo
    Nodyn

    DETERMINISTIC = GWIR
    Rhaid ei ddatgan yn benodol fel nodwedd o ddull Microsoft .NET Framework.

    Cywir = GWIR
    Rhaid ei ddatgan yn benodol fel nodwedd o'r dull Fframwaith .NET.

    MYNEDIAD DATA = DIM SQL
    Wedi'i benderfynu trwy osod priodoledd DataAccess i DataAccessKind.None a phriodoledd SystemDataAccess i SystemDataAccessKind.None.

    MYNEDIAD ALLANOL = RHIF
    Mae'r eiddo hwn yn ddiofyn i NA ar gyfer arferion CLR.

  • Rhaid creu'r olygfa trwy ddefnyddio'r WITH SCHEMABINDING opsiwn.
  • Rhaid i'r olwg gyfeirio at dablau sylfaen yn unig sydd yn yr un gronfa ddata â'r olygfa. Ni all y farn gyfeirio at safbwyntiau eraill.
  • Ni ddylai'r datganiad SELECT yn y diffiniad golygfa gynnwys yr elfennau Transact-SQL canlynol:

    COUNT
    ffwythiannau ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, A OPENXML)
    OUTER yn ymuno (LEFT, RIGHT, neu FULL)

    Tabl deilliedig (a ddiffinnir gan nodi a SELECT datganiad yn y FROM cymal)
    Hunan-ymuno
    Pennu colofnau trwy ddefnyddio SELECT * or SELECT <table_name>.*

    DISTINCT
    STDEV, STDEVP, VAR, VARP, neu AVG
    Mynegiant tabl cyffredin (CTE)

    arnofio1, testun, ntestun, image, XML, neu ffrwd ffeil colofnau
    Subquery
    OVER cymal, sy'n cynnwys swyddogaethau graddio neu ffenestr gyfanredol

    Rhagfynegiadau testun llawn (CONTAINS, FREETEXT)
    SUM swyddogaeth sy'n cyfeirio at fynegiad nulladwy
    ORDER BY

    Swyddogaeth agregau a ddiffinnir gan ddefnyddwyr CLR
    TOP
    CUBE, ROLLUP, neu GROUPING SETS gweithredwyr

    MIN, MAX
    UNION, EXCEPT, neu INTERSECT gweithredwyr
    TABLESAMPLE

    Newidynnau tabl
    OUTER APPLY or CROSS APPLY
    PIVOT, UNPIVOT

    Setiau colofn denau
    Swyddogaethau mewn-lein (TVF) neu aml-ddatganiad gwerth tabl (MSTVF)
    OFFSET

    CHECKSUM_AGG

    1 Gall y golwg mynegeio gynnwys arnofio colofnau; fodd bynnag, ni ellir cynnwys colofnau o'r fath yn yr allwedd fynegai wedi'i chlystyru.

  • If GROUP BY yn bresennol, rhaid i'r diffiniad VIEW gynnwys COUNT_BIG(*) a rhaid iddo beidio â chynnwys HAVING. Mae'r rhain yn GROUP BY cyfyngiadau yn berthnasol i'r diffiniad golwg mynegeiedig yn unig. Gall ymholiad ddefnyddio gwedd wedi'i fynegeio yn ei gynllun gweithredu hyd yn oed os nad yw'n bodloni'r rhain GROUP BY cyfyngiadau.
  • Os yw'r diffiniad golygfa yn cynnwys a GROUP BY cymal, gall allwedd y mynegai clystyrog unigryw gyfeirio at y colofnau a nodir yn y GROUP BY cymal.

Mae'n amlwg yma nad oedd yr Indiaid yn cymryd rhan, gan eu bod wedi penderfynu ei wneud yn ôl y cynllun "ni fyddwn yn gwneud fawr ddim, ond yn dda." Hynny yw, mae ganddyn nhw fwy o fwyngloddiau ar y cae, ond mae eu lleoliad yn fwy tryloyw. Y peth mwyaf siomedig yw'r cyfyngiad hwn:

Rhaid i'r olwg gyfeirio at dablau sylfaen yn unig sydd yn yr un gronfa ddata â'r olygfa. Ni all y farn gyfeirio at safbwyntiau eraill.

Yn ein terminoleg, mae hyn yn golygu na all swyddogaeth gael mynediad at swyddogaeth arall sydd wedi'i gwireddu. Mae hyn yn lleihau'r holl ideoleg yn y blagur.
Hefyd, mae'r cyfyngiad hwn (ac ymhellach yn y testun) yn lleihau'r achosion defnydd yn fawr:

Ni ddylai'r datganiad SELECT yn y diffiniad golygfa gynnwys yr elfennau Transact-SQL canlynol:

COUNT
ffwythiannau ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, A OPENXML)
OUTER yn ymuno (LEFT, RIGHT, neu FULL)

Tabl deilliedig (a ddiffinnir gan nodi a SELECT datganiad yn y FROM cymal)
Hunan-ymuno
Pennu colofnau trwy ddefnyddio SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, neu AVG
Mynegiant tabl cyffredin (CTE)

arnofio1, testun, ntestun, image, XML, neu ffrwd ffeil colofnau
Subquery
OVER cymal, sy'n cynnwys swyddogaethau graddio neu ffenestr gyfanredol

Rhagfynegiadau testun llawn (CONTAINS, FREETEXT)
SUM swyddogaeth sy'n cyfeirio at fynegiad nulladwy
ORDER BY

Swyddogaeth agregau a ddiffinnir gan ddefnyddwyr CLR
TOP
CUBE, ROLLUP, neu GROUPING SETS gweithredwyr

MIN, MAX
UNION, EXCEPT, neu INTERSECT gweithredwyr
TABLESAMPLE

Newidynnau tabl
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Setiau colofn denau
Swyddogaethau mewn-lein (TVF) neu aml-ddatganiad gwerth tabl (MSTVF)
OFFSET

CHECKSUM_AGG

YMUNIADAU ALLANOL, UNDEB, GORCHYMYN GAN ac eraill yn cael eu gwahardd. Efallai y byddai wedi bod yn haws nodi'r hyn y gellid ei ddefnyddio yn hytrach na'r hyn na ellid ei ddefnyddio. Mae'n debyg y byddai'r rhestr yn llawer byrrach.

I grynhoi: set enfawr o gyfyngiadau ym mhob (gadewch i ni nodi masnachol) DBMS vs dim (ac eithrio un rhesymegol, nid technegol) mewn technoleg LGPL. Fodd bynnag, dylid nodi bod gweithredu'r mecanwaith hwn mewn rhesymeg berthynol ychydig yn anoddach nag yn y rhesymeg swyddogaethol a ddisgrifir.

Gweithredu

Sut mae'n gweithio? Defnyddir PostgreSQL fel “peiriant rhithwir”. Mae algorithm cymhleth y tu mewn sy'n adeiladu ymholiadau. Yma ffynhonnell. Ac nid dim ond set fawr o heuristics sydd gyda llawer o bethau. Felly, os oes gennych ychydig fisoedd i astudio, gallwch geisio deall pensaernïaeth.

A yw'n gweithio'n effeithiol? Eithaf effeithiol. Yn anffodus, mae hyn yn anodd ei brofi. Ni allaf ond dweud os ydych yn ystyried y miloedd o ymholiadau sy'n bodoli mewn ceisiadau mawr, yna ar gyfartaledd maent yn fwy effeithlon na rhai datblygwr da. Gall rhaglennydd SQL rhagorol ysgrifennu unrhyw ymholiad yn fwy effeithlon, ond gyda mil o ymholiadau yn syml, ni fydd ganddo'r cymhelliant na'r amser i'w wneud. Yr unig beth y gallaf ei ddyfynnu nawr fel prawf o effeithiolrwydd yw bod sawl prosiect yn gweithio ar y platfform sydd wedi'i adeiladu ar y DBMS hwn Systemau ERP, sydd â miloedd o wahanol swyddogaethau MATERIALIZED, gyda miloedd o ddefnyddwyr a chronfeydd data terabyte gyda channoedd o filiynau o gofnodion yn rhedeg ar weinydd dwy-brosesydd rheolaidd. Fodd bynnag, gall unrhyw un wirio / gwrthbrofi'r effeithiolrwydd trwy lawrlwytho platfform a PostgreSQL, troi ymlaen logio ymholiadau SQL a cheisio newid y rhesymeg a'r data yno.

Yn yr erthyglau canlynol, byddaf hefyd yn siarad am sut y gallwch chi osod cyfyngiadau ar swyddogaethau, gweithio gyda sesiynau newid, a llawer mwy.

Ffynhonnell: hab.com

Ychwanegu sylw