ProHoster > blog > Utawala > Kusawazisha huandika na kusoma katika hifadhidata

Kusawazisha huandika na kusoma katika hifadhidata

Kusawazisha huandika na kusoma katika hifadhidata
Katika uliopita Ibara ya Nilielezea dhana na utekelezaji wa hifadhidata iliyojengwa kwa misingi ya kazi, badala ya majedwali na nyanja kama katika hifadhidata za uhusiano. Ilitoa mifano mingi inayoonyesha faida za mbinu hii juu ya ile ya zamani. Wengi waliwaona hawashawishiki vya kutosha.

Katika makala hii, nitaonyesha jinsi dhana hii inakuwezesha kusawazisha kwa haraka na kwa urahisi kuandika na kusoma kwenye hifadhidata bila mabadiliko yoyote katika mantiki ya uendeshaji. Utendaji sawia umejaribiwa kutekelezwa katika DBMS za kisasa za kibiashara (haswa, Oracle na Seva ya Microsoft SQL). Mwishoni mwa makala nitaonyesha kwamba walichofanya, ili kuiweka kwa upole, haikufanya kazi vizuri sana.

Description

Kama hapo awali, kwa ufahamu bora nitaanza maelezo na mifano. Wacha tuseme tunahitaji kutekeleza mantiki ambayo itarudisha orodha ya idara na idadi ya wafanyikazi ndani yao na jumla ya mshahara wao.

Katika hifadhidata inayofanya kazi ingeonekana kama hii:

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

Utata wa kutekeleza hoja hii katika DBMS yoyote itakuwa sawa na O (idadi ya wafanyikazi)kwa sababu hesabu hii inahitaji kuchambua meza nzima ya wafanyikazi na kisha kuwapanga kulingana na idara. Pia kutakuwa na nyongeza ndogo (tunaamini kuwa kuna wafanyikazi wengi zaidi kuliko idara) kulingana na mpango uliochaguliwa O (logi nambari ya wafanyikazi) au O (idadi ya idara) kwa makundi na kadhalika.

Ni wazi kwamba uendeshaji wa juu unaweza kuwa tofauti katika DBMS tofauti, lakini utata hautabadilika kwa njia yoyote.

Katika utekelezaji uliopendekezwa, DBMS inayofanya kazi itatoa subquery moja ambayo itahesabu maadili yanayohitajika kwa idara, na kisha kufanya JIUNGE na jedwali la idara ili kupata jina. Hata hivyo, kwa kila kazi, wakati wa kutangaza, inawezekana kuweka alama maalum ya MATERIALIZED. Mfumo utaunda kiotomati uwanja unaolingana kwa kila kazi kama hiyo. Wakati wa kubadilisha thamani ya chaguo za kukokotoa, thamani ya sehemu pia itabadilika katika shughuli hiyo hiyo. Wakati wa kufikia kipengele hiki, uwanja uliohesabiwa awali utapatikana.

Hasa, ikiwa utaweka MATERIALIZED kwa vitendakazi hesabu ya Wafanyakazi и mshaharaSum, basi mashamba mawili yataongezwa kwenye meza na orodha ya idara, ambayo itahifadhi idadi ya wafanyakazi na mshahara wao wote. Wakati wowote kuna mabadiliko ya wafanyikazi, mishahara yao au ushirika wa idara, mfumo utabadilisha kiatomati maadili ya nyanja hizi. Hoja iliyo hapo juu itafikia sehemu hizi moja kwa moja na itatekelezwa O (idadi ya idara).

Vizuizi ni nini? Jambo moja tu: chaguo la kukokotoa kama hilo lazima liwe na nambari maalum ya maadili ya uingizaji ambayo thamani yake imefafanuliwa. Vinginevyo, haitawezekana kujenga meza ambayo huhifadhi maadili yake yote, kwani hawezi kuwa na meza yenye idadi isiyo na kipimo ya safu.

Mfano:

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

Chaguo hili la kukokotoa linafafanuliwa kwa idadi isiyo na kikomo ya maadili ya nambari N (kwa mfano, thamani yoyote hasi inafaa). Kwa hivyo, huwezi kuweka MATERIALIZED juu yake. Kwa hivyo hii ni kizuizi cha kimantiki, sio cha kiufundi (hiyo ni, sio kwa sababu hatukuweza kuitekeleza). Vinginevyo, hakuna vikwazo. Unaweza kutumia vikundi, kupanga, NA na AU, PARTITION, kujirudia, n.k.

Kwa mfano, katika shida ya 2.2 ya kifungu kilichopita, unaweza kuweka MATERIALIZED kwenye kazi zote mbili:

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;

Mfumo yenyewe utaunda meza moja na funguo za aina Wateja, Bidhaa и INTEGER, itaongeza sehemu mbili kwake na itasasisha thamani za uga ndani yake na mabadiliko yoyote. Wakati simu zaidi kwa kazi hizi zinafanywa, hazitahesabiwa, lakini badala yake maadili yatasomwa kutoka kwa sehemu zinazolingana.

Kwa kutumia utaratibu huu, unaweza, kwa mfano, kujiondoa kujirudia (CTE) katika maswali. Hasa, zingatia vikundi vinavyounda mti kwa kutumia uhusiano wa mtoto/mzazi (kila kikundi kina kiunga cha mzazi wake):

parent = DATA Group (Group);

Katika hifadhidata inayofanya kazi, mantiki ya kujirudia inaweza kubainishwa kama ifuatavyo:

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;

Tangu kwa kazi niMzazi imewekwa alama ya MATERIALIZED, kisha meza iliyo na funguo mbili (vikundi) itaundwa kwa ajili yake, ambayo shamba niMzazi itakuwa kweli ikiwa tu ufunguo wa kwanza ni mtoto wa pili. Idadi ya maingizo katika jedwali hili itakuwa sawa na idadi ya vikundi vinavyozidishwa na kina cha wastani cha mti. Ikiwa unahitaji, kwa mfano, kuhesabu idadi ya wazao wa kikundi fulani, unaweza kutumia kazi hii:

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

Hakutakuwa na CTE katika hoja ya SQL. Badala yake kutakuwa na KUNDI rahisi BY.

Kwa kutumia utaratibu huu, unaweza pia kubadilisha hifadhidata kwa urahisi ikiwa ni lazima:

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

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

Unapoita kipengele tarehe kwa mstari wa utaratibu, shamba ambalo kuna index itasomwa kutoka kwa meza na mistari ya utaratibu. Tarehe ya kuagiza inapobadilika, mfumo wenyewe utahesabu upya kiotomatiki tarehe iliyorekebishwa kwenye mstari.

Faida

Utaratibu huu wote ni wa nini? Katika DBMS za kawaida, bila maswali ya kuandika upya, msanidi programu au DBA inaweza tu kubadilisha faharasa, kubainisha takwimu na kumwambia mpangaji hoja jinsi ya kuzitekeleza (na Madokezo yanapatikana katika DBMS za kibiashara pekee). Haijalishi wanajaribu sana, hawataweza kukamilisha swali la kwanza kwenye kifungu O (idadi ya idara) bila kubadilisha maswali au kuongeza vichochezi. Katika mpango uliopendekezwa, katika hatua ya ukuzaji sio lazima ufikirie juu ya muundo wa uhifadhi wa data na ni miunganisho gani ya kutumia. Yote hii inaweza kubadilishwa kwa urahisi juu ya kuruka, moja kwa moja katika uendeshaji.

Katika mazoezi inaonekana kama hii. Watu wengine huendeleza mantiki moja kwa moja kulingana na kazi iliyopo. Hawaelewi algoriti na uchangamano wao, wala mipango ya utekelezaji, wala aina za viungio, wala sehemu nyingine yoyote ya kiufundi. Watu hawa ni wachambuzi zaidi wa biashara kuliko watengenezaji. Kisha, yote haya huenda katika kupima au uendeshaji. Huwasha uwekaji kumbukumbu wa hoja za muda mrefu. Swali refu linapogunduliwa, basi watu wengine (kiufundi zaidi - kimsingi DBA) huamua kuwasha MATERIALIZED kwenye utendaji fulani wa kati. Hii inapunguza kasi ya kurekodi kidogo (kwani inahitaji kusasisha sehemu ya ziada katika muamala). Hata hivyo, sio tu swala hili linaharakishwa kwa kiasi kikubwa, lakini pia wengine wote wanaotumia kazi hii. Wakati huo huo, kuamua ni kazi gani ya kutengenezea ni rahisi. Vigezo viwili kuu: idadi ya maadili yanayowezekana ya pembejeo (hii ndio rekodi ngapi zitakuwa kwenye jedwali linalolingana), na ni mara ngapi hutumiwa katika kazi zingine.

Analogs

DBMS za kisasa za kibiashara zina mbinu zinazofanana: MATATIZO ILIYO NA RUFUSHA HARAKA (Oracle) na INDEXED VIEW (Seva ya Microsoft SQL). Katika PostgreSQL, MTAZAMO WA MATARIALIZED hauwezi kusasishwa katika shughuli, lakini kwa ombi tu (na hata kwa vizuizi vikali), kwa hivyo hatuzingatii. Lakini wana matatizo kadhaa ambayo hupunguza matumizi yao kwa kiasi kikubwa.

Kwanza, unaweza kuwezesha uboreshaji ikiwa tayari umeunda VIEW ya kawaida. Vinginevyo, itabidi uandike upya maombi yaliyosalia ili kufikia mwonekano mpya ulioundwa ili kutumia uboreshaji huu. Au acha kila kitu kama kilivyo, lakini haitakuwa na ufanisi ikiwa kuna data fulani tayari iliyohesabiwa, lakini maswali mengi hayatumii kila wakati, lakini huhesabu tena.

Pili, wana idadi kubwa ya vikwazo:

Oracle

5.3.8.4 Vikwazo vya Jumla kwa Upyaji upya haraka

Hoja ya kufafanua ya mwonekano wa nyenzo imezuiwa kama ifuatavyo:

  • Mtazamo uliobadilishwa lazima usiwe na marejeleo ya misemo isiyojirudia kama vile SYSDATE na ROWNUM.
  • Mtazamo uliobadilishwa lazima usiwe na marejeleo ya RAW or LONG RAW aina za data.
  • Haiwezi kuwa na a SELECT orodha ndogo ya maswali.
  • Haiwezi kuwa na vitendaji vya uchanganuzi (kwa mfano, RANK) ndani ya SELECT Kifungu.
  • Haiwezi kurejelea jedwali ambalo a XMLIndex index imefafanuliwa.
  • Haiwezi kuwa na a MODEL Kifungu.
  • Haiwezi kuwa na a HAVING kifungu chenye hoja ndogo.
  • Haiwezi kuwa na maswali yaliyowekwa ANY, ALL, Au NOT EXISTS.
  • Haiwezi kuwa na a [START WITH …] CONNECT BY Kifungu.
  • Haiwezi kuwa na jedwali nyingi za maelezo kwenye tovuti tofauti.
  • ON COMMIT maoni yanayoonekana hayawezi kuwa na majedwali ya maelezo ya mbali.
  • Mionekano iliyobandikwa lazima iwe na unganisho au jumla.
  • Mionekano ya uunganisho iliyoboreshwa na mionekano ya jumla iliyofanywa na a GROUP BY kifungu hakiwezi kuchagua kutoka kwa jedwali lililopangwa kwa faharasa.

5.3.8.5 Vikwazo vya Kuonyesha upya Haraka kwenye Mionekano Inayotumika kwa Viunga Pekee

Kufafanua hoja za maoni yaliyobadilishwa kwa viungio pekee na hakuna mkusanyiko kuna vizuizi vifuatavyo vya kuonyesha upya haraka:

  • Vizuizi vyote kutoka kwa «Vizuizi vya Jumla kwa Upyaji upya haraka".
  • Hawawezi kuwa nayo GROUP BY vifungu au jumla.
  • Mistari ya meza zote katika FROM orodha lazima ionekane kwenye SELECT orodha ya swali.
  • Kumbukumbu za mwonekano ulioboreshwa lazima ziwepo na safu safu kwa majedwali yote ya msingi kwenye FROM orodha ya swali.
  • Huwezi kuunda mwonekano wa haraka unaoweza kuonyeshwa upya kutoka kwa majedwali mengi na viungio rahisi ambavyo vinajumuisha safu wima ya aina ya kitu kwenye SELECT kauli.

Pia, njia ya kuonyesha upya utakayochagua haitakuwa na ufanisi ipasavyo ikiwa:

  • Hoja ya kubainisha hutumia kiunganishi cha nje ambacho kinafanya kazi kama kiungo cha ndani. Ikiwa hoja inayobainisha ina kiunganishi kama hicho, zingatia kuandika upya hoja ya kubainisha ili iwe na muunganisho wa ndani.
  • The SELECT orodha ya mwonekano uliobadilishwa ina misemo kwenye safu wima kutoka kwa majedwali mengi.

5.3.8.6 Vikwazo vya Upyaji upya Haraka kwenye Mionekano Inayotumika kwa Jumla

Kufafanua hoja za maoni yaliyobadilishwa na mijumlisho au viungio kuna vikwazo vifuatavyo vya kuonyesha upya haraka:

Kuonyesha upya haraka kunatumika kwa zote mbili ON COMMIT na ON DEMAND maoni yanayoonekana, hata hivyo vikwazo vifuatavyo vinatumika:

  • Jedwali zote katika mwonekano wa umbile lazima ziwe na kumbukumbu za kuonekana, na kumbukumbu za mwonekano zilizobadilishwa lazima:
    • Ina safu wima zote kutoka kwa jedwali linalorejelewa katika mwonekano uliobadilishwa.
    • Bainisha na ROWID na INCLUDING NEW VALUES.
    • kutaja SEQUENCE kifungu ikiwa jedwali linatarajiwa kuwa na mchanganyiko wa viingilio/vipakiaji-moja kwa moja, kufuta, na masasisho.

  • Tu SUM, COUNT, AVG, STDDEV, VARIANCE, MIN na MAX zinatumika kwa kusasisha haraka.
  • COUNT(*) lazima ibainishwe.
  • Jukumu la kukokotoa lazima litokee tu kama sehemu ya nje ya usemi. Hiyo ni, aggregates kama vile AVG(AVG(x)) or AVG(x)+ AVG(x) haziruhusiwi.
  • Kwa kila jumla ya mabao kama vile AVG(expr), sambamba COUNT(expr) lazima kuwepo. Oracle anapendekeza hivyo SUM(expr) kubainishwa.
  • If VARIANCE(expr) or STDDEV(expr) imebainishwa, COUNT(expr) na SUM(expr) lazima ibainishwe. Oracle anapendekeza hivyo SUM(expr *expr) kubainishwa.
  • The SELECT safu katika hoja ya kubainisha haiwezi kuwa usemi changamano wenye safu wima kutoka kwa majedwali mengi ya msingi. Suluhu inayowezekana kwa hili ni kutumia mwonekano uliowekwa kiota.
  • The SELECT orodha lazima iwe na yote GROUP BY nguzo.
  • Mwonekano wa kuonekana hautegemei jedwali moja au zaidi za mbali.
  • Ikiwa unatumia a CHAR aina ya data katika safu wima za kichujio cha logi ya mwonekano iliyobadilishwa, seti za herufi za tovuti kuu na mwonekano wa nyenzo lazima ziwe sawa.
  • Ikiwa mwonekano wa umbile una mojawapo ya yafuatayo, basi uonyeshaji upya haraka unaauniwa tu kwenye vichochezi vya kawaida vya DML na mizigo ya moja kwa moja.
    • Maoni ya nyenzo na MIN or MAX mkusanyiko
    • Maoni ya nyenzo ambayo yana SUM(expr) lakini hapana COUNT(expr)
    • Mionekano ya nyenzo bila COUNT(*)

    Mtazamo kama huo wa kibinadamu unaitwa mtazamo wa kuingizwa tu.

  • Mtazamo unaoonekana na MAX or MIN inaonyeshwa upya kwa haraka baada ya kufuta au kuchanganya taarifa za DML ikiwa haina a WHERE Kifungu.
    Usasishaji wa kasi wa juu kwa dakika baada ya kufuta au mchanganyiko wa DML hauna tabia sawa na kesi ya kuingiza pekee. Inafuta na kurudisha thamani za juu/min kwa vikundi vilivyoathiriwa. Unahitaji kufahamu athari zake za utendaji.
  • Mitazamo iliyoboreshwa yenye mitazamo iliyotajwa au hoja ndogo katika FROM kifungu kinaweza kusasishwa haraka mradi maoni yanaweza kuunganishwa kabisa. Kwa habari kuhusu maoni ambayo yataunganishwa, ona Marejeleo ya Lugha ya Oracle Database SQL.
  • Ikiwa hakuna viungio vya nje, unaweza kuwa na chaguo kiholela na kujiunga kwenye WHERE Kifungu.
  • Mionekano ya jumla iliyoboreshwa yenye viungio vya nje huonyeshwa upya kwa haraka baada ya DML ya kawaida na mizigo ya moja kwa moja, mradi tu jedwali la nje limerekebishwa. Pia, vikwazo vya kipekee lazima viwepo kwenye safu wima za uunganisho wa jedwali la ndani la kuunganisha. Ikiwa kuna viungio vya nje, viungio vyote lazima viunganishwe na ANDs na lazima kutumia usawa (=) mwendeshaji.
  • Kwa maoni yanayoonekana na CUBE, ROLLUP, seti za vikundi, au uunganishaji wao, vikwazo vifuatavyo vinatumika:
    • The SELECT list inapaswa kuwa na kitofautishi cha kambi ambacho kinaweza kuwa a GROUPING_ID kazi kwa wote GROUP BY maneno au GROUPING kazi moja kwa kila moja GROUP BY kujieleza. Kwa mfano, ikiwa GROUP BY kifungu cha mtazamo unaoonekana ni "GROUP BY CUBE(a, b)", kisha SELECT orodha inapaswa kuwa na "GROUPING_ID(a, b)»au «GROUPING(a) AND GROUPING(b)»ili mwonekano wa kuonekana uweze kuonyeshwa kwa haraka.
    • GROUP BY haipaswi kusababisha vikundi vyovyote vinavyorudiwa. Kwa mfano, "GROUP BY a, ROLLUP(a, b)" hairudishwi haraka kwa sababu inasababisha makundi yanayorudiwa "(a), (a, b), AND (a)".

5.3.8.7 Vikwazo vya Kuonyesha upya Haraka kwenye Maoni ya Nyenzo na MUUNGANO WOTE

Maoni ya nyenzo na UNION ALL kuweka msaada wa operator REFRESH FAST chaguo ikiwa masharti yafuatayo yametimizwa:

  • Swali la kufafanua lazima liwe na UNION ALL operator katika ngazi ya juu.

    The UNION ALL opereta haiwezi kupachikwa ndani ya hoja ndogo, isipokuwa moja: The UNION ALL inaweza kuwa katika subquery katika FROM kifungu kilichotolewa hoja ya kufafanua ni ya fomu SELECT * FROM (tazama au uliza kidogo na UNION ALL) kama katika mfano ufuatao:

    TUNZA Mwonekano_na_umoja wote AS (CHAGUA kridi ya c.rowid, c.cust_id, alama 2 KUTOKA KWA wateja c WAPI c.cust_last_name = 'Smith' UNION WOTE CHAGUA c.rowid crid, c.cust_id, 3 marker KUTOKA kwa wateja c WAPI c.cust_last_last_ 'Jones'); TUNDA MTAZAMO ULIO NA MADILIFU unionall_inside_view_mv RUSHA HARAKA UNAHITAJI KAMA CHAGUA * KUTOKA kwa view_with_unionall;

    Kumbuka kwamba mtazamo view_with_unionall inakidhi mahitaji ya kuonyesha upya haraka.

  • Kila kizuizi cha swali kwenye faili ya UNION ALL swala lazima likidhi mahitaji ya mwonekano wa haraka unaoweza kuonyeshwa upya na mijumlisho au mwonekano wa haraka unaoweza kuonyeshwa upya na viungio.

    Kumbukumbu zinazofaa za kuonekana lazima ziundwe kwenye majedwali kama inavyohitajika kwa aina inayolingana ya mwonekano unaorudishwa haraka.
    Kumbuka kuwa Hifadhidata ya Oracle pia inaruhusu kesi maalum ya mwonekano wa maandishi ya jedwali moja na viungio vilivyotolewa tu ROWID safu imejumuishwa katika SELECT orodha na katika logi ya kutazama iliyofanywa. Hii inaonyeshwa katika swali la kufafanua la mtazamo view_with_unionall.

  • The SELECT orodha ya kila swali lazima iwe na a UNION ALL alama, na UNION ALL safu lazima iwe na nambari tofauti au thamani ya mfuatano katika kila moja UNION ALL tawi. Zaidi ya hayo, safu wima ya alama lazima ionekane katika nafasi sawa ya mpangilio katika SELECT orodha ya kila kizuizi cha hoja. Angalia"UNION Alama YOTE na Hoja Andika Upya»kwa habari zaidi kuhusu UNION ALL alama.
  • Baadhi ya vipengele kama vile viungio vya nje, hoja za mwonekano wa jumla wa kujumlisha pekee na majedwali ya mbali hayatumiki kwa mionekano inayoonekana na UNION ALL. Kumbuka, hata hivyo, kwamba maoni yaliyobadilishwa yanayotumiwa katika urudufishaji, ambayo hayana viungio au mkusanyiko, yanaweza kusasishwa haraka wakati. UNION ALL au meza za mbali hutumiwa.
  • Kigezo cha uanzishaji wa uoanifu lazima kiwekwe 9.2.0 au zaidi ili kuunda mwonekano wa haraka unaoweza kuonyeshwa upya na UNION ALL.

Sitaki kuwaudhi mashabiki wa Oracle, lakini kwa kuzingatia orodha yao ya vizuizi, inaonekana kwamba utaratibu huu haukuandikwa katika kesi ya jumla, kwa kutumia aina fulani ya mfano, lakini na maelfu ya Wahindi, ambapo kila mtu alipewa fursa ya kuandika tawi lao wenyewe, na kila mmoja wao alifanya alivyoweza. Kutumia utaratibu huu kwa mantiki halisi ni kama kutembea kwenye uwanja wa migodi. Unaweza kupata mgodi wakati wowote kwa kupiga moja ya vikwazo visivyo wazi. Jinsi inavyofanya kazi pia ni swali tofauti, lakini ni zaidi ya upeo wa kifungu hiki.

Microsoft SQL Server

Mahitaji ya Ziada

Kwa kuongeza chaguzi za SET na mahitaji ya utendakazi ya kuamua, mahitaji yafuatayo lazima yatimizwe:

  • Mtumiaji anayetekeleza CREATE INDEX lazima awe mmiliki wa mtazamo.
  • Unapounda index, the IGNORE_DUP_KEY chaguo lazima liwekwe ZIMWA (mipangilio ya chaguo-msingi).
  • Jedwali lazima lirejelewe kwa majina ya sehemu mbili, schema.jina la meza katika ufafanuzi wa mtazamo.
  • Vitendo vilivyoainishwa na mtumiaji vinavyorejelewa kwenye mwonekano lazima viundwe kwa kutumia WITH SCHEMABINDING chaguo.
  • Kazi zozote zilizoainishwa na mtumiaji zilizorejelewa katika mwonekano lazima zirejelewe kwa majina ya sehemu mbili, ..
  • Sifa ya ufikiaji wa data ya kitendakazi kilichobainishwa na mtumiaji lazima kiwe NO SQL, na mali ya ufikiaji wa nje lazima iwe NO.
  • Vitendo vya kukokotoa vya wakati wa kutumia lugha ya kawaida (CLR) vinaweza kuonekana katika orodha iliyochaguliwa ya mwonekano, lakini haziwezi kuwa sehemu ya ufafanuzi wa ufunguo wa faharasa uliounganishwa. Chaguo za kukokotoa za CLR haziwezi kuonekana katika kifungu cha WHERE cha mtazamo au kifungu cha ON cha operesheni ya JIUNGE kwenye mwonekano.
  • Chaguo za kukokotoa za CLR na mbinu za aina zilizobainishwa na mtumiaji za CLR zinazotumika katika ufafanuzi wa mwonekano lazima ziwe na sifa zilizowekwa kama inavyoonyeshwa kwenye jedwali lifuatalo.

    mali
    Kumbuka

    DETERMINISTIC = TRUE
    Lazima itangazwe kwa uwazi kama sifa ya mbinu ya Microsoft .NET Framework.

    SAHIHI = KWELI
    Lazima itangazwe kwa uwazi kama sifa ya mbinu ya .NET Framework.

    UPATIKANAJI WA DATA = HAKUNA SQL
    Imebainishwa kwa kuweka sifa ya DataAccess kwa DataAccessKind.None na SystemDataAccess sifa ya SystemDataAccessKind.None.

    UPATIKANAJI WA NJE = NO
    Sifa hii ni chaguomsingi kuwa HAPANA kwa taratibu za CLR.

  • Mtazamo lazima uundwe kwa kutumia WITH SCHEMABINDING chaguo.
  • Mwonekano lazima urejelee majedwali ya msingi pekee yaliyo katika hifadhidata sawa na mwonekano. Mtazamo hauwezi kurejelea maoni mengine.
  • Taarifa ya SELECT katika ufafanuzi wa mwonekano lazima isiwe na vipengele vifuatavyo vya Transact-SQL:

    COUNT
    Vitendaji vya ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSETNA OPENXML)
    OUTER kujiunga (LEFT, RIGHT, Au FULL)

    Jedwali linalotokana (limefafanuliwa kwa kubainisha a SELECT kauli katika FROM kifungu)
    Kujiunga binafsi
    Kubainisha safu kwa kutumia SELECT * or SELECT <table_name>.*

    DISTINCT
    STDEV, STDEVP, VAR, VARP, Au AVG
    Usemi wa jedwali la kawaida (CTE)

    kuelea1, Nakala, maandishi, picha, XML, Au mkondo wa faili nguzo
    Maswali madogo
    OVER kifungu, ambacho kinajumuisha kazi za kuorodhesha au kujumlisha dirisha

    Vihusishi vya maandishi kamili (CONTAINS, FREETEXT)
    SUM kazi inayorejelea usemi unaobatilika
    ORDER BY

    Chaguo za kukokotoa za CLR zilizobainishwa na mtumiaji
    TOP
    CUBE, ROLLUP, Au GROUPING SETS operators

    MIN, MAX
    UNION, EXCEPT, Au INTERSECT operators
    TABLESAMPLE

    Vigezo vya jedwali
    OUTER APPLY or CROSS APPLY
    PIVOT, UNPIVOT

    Seti za safu wima chache
    Inline (TVF) au vitendaji vyenye thamani ya jedwali la kauli nyingi (MSTVF)
    OFFSET

    CHECKSUM_AGG

    1 Mwonekano uliowekwa kwenye faharasa unaweza kuwa na kuelea nguzo; hata hivyo, safu wima kama hizo haziwezi kujumuishwa katika ufunguo wa faharasa uliounganishwa.

  • If GROUP BY iko, ufafanuzi wa VIEW lazima uwe na COUNT_BIG(*) na lazima isiwe na HAVING. Hizi GROUP BY vikwazo vinatumika tu kwa ufafanuzi wa mtazamo uliowekwa kwenye faharasa. Hoja inaweza kutumia mwonekano uliowekwa katika faharasa katika mpango wake wa utekelezaji hata kama haikidhi haya GROUP BY vikwazo.
  • Ikiwa ufafanuzi wa mtazamo una a GROUP BY kifungu, ufunguo wa faharasa ya kipekee iliyounganishwa inaweza kurejelea safu wima zilizobainishwa tu kwenye GROUP BY Kifungu.

Ni wazi hapa kwamba Wahindi hawakuhusika, kwani waliamua kuifanya kulingana na mpango "tutafanya kidogo, lakini vizuri." Yaani wana migodi mingi uwanjani, lakini eneo lao ni la uwazi zaidi. Jambo la kukatisha tamaa zaidi ni kizuizi hiki:

Mwonekano lazima urejelee majedwali ya msingi pekee yaliyo katika hifadhidata sawa na mwonekano. Mtazamo hauwezi kurejelea maoni mengine.

Katika istilahi zetu, hii ina maana kwamba kipengele cha chaguo za kukokotoa hakiwezi kufikia utendaji mwingine unaoonekana. Hii inapunguza itikadi zote kwenye chipukizi.
Pia, kizuizi hiki (na zaidi katika maandishi) hupunguza sana kesi za utumiaji:

Taarifa ya SELECT katika ufafanuzi wa mwonekano lazima isiwe na vipengele vifuatavyo vya Transact-SQL:

COUNT
Vitendaji vya ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSETNA OPENXML)
OUTER kujiunga (LEFT, RIGHT, Au FULL)

Jedwali linalotokana (limefafanuliwa kwa kubainisha a SELECT kauli katika FROM kifungu)
Kujiunga binafsi
Kubainisha safu kwa kutumia SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, Au AVG
Usemi wa jedwali la kawaida (CTE)

kuelea1, Nakala, maandishi, picha, XML, Au mkondo wa faili nguzo
Maswali madogo
OVER kifungu, ambacho kinajumuisha kazi za kuorodhesha au kujumlisha dirisha

Vihusishi vya maandishi kamili (CONTAINS, FREETEXT)
SUM kazi inayorejelea usemi unaobatilika
ORDER BY

Chaguo za kukokotoa za CLR zilizobainishwa na mtumiaji
TOP
CUBE, ROLLUP, Au GROUPING SETS operators

MIN, MAX
UNION, EXCEPT, Au INTERSECT operators
TABLESAMPLE

Vigezo vya jedwali
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Seti za safu wima chache
Inline (TVF) au vitendaji vyenye thamani ya jedwali la kauli nyingi (MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOINS, MUUNGANO, ORDER BY na wengine ni marufuku. Huenda ikawa rahisi kubainisha ni nini kingeweza kutumika badala ya kile ambacho hakingeweza kutumika. Orodha labda ingekuwa fupi zaidi.

Kwa muhtasari: seti kubwa ya vikwazo katika kila (hebu tukumbuke kibiashara) DBMS dhidi ya hakuna (isipokuwa moja ya kimantiki, si ya kiufundi) katika teknolojia ya LGPL. Hata hivyo, ni lazima ieleweke kwamba kutekeleza utaratibu huu katika mantiki ya uhusiano ni vigumu zaidi kuliko katika mantiki ya kazi iliyoelezwa.

Utekelezaji

Inavyofanya kazi? PostgreSQL inatumika kama "mashine halisi". Kuna algorithm tata ndani ambayo huunda maswali. Hapa msimbo wa chanzo. Na hakuna tu seti kubwa ya heuristics na rundo la ifs. Kwa hivyo, ikiwa una miezi michache ya kusoma, unaweza kujaribu kuelewa usanifu.

Je, inafanya kazi kwa ufanisi? Ufanisi kabisa. Kwa bahati mbaya, hii ni ngumu kudhibitisha. Ninaweza kusema tu kwamba ikiwa unazingatia maelfu ya maombi yaliyopo katika maombi makubwa, basi kwa wastani yanafaa zaidi kuliko yale ya msanidi mzuri. Mpangaji programu bora wa SQL anaweza kuandika swali lolote kwa ufanisi zaidi, lakini kwa maswali elfu moja hatakuwa na motisha au wakati wa kuifanya. Kitu pekee ninachoweza kutaja kama dhibitisho la ufanisi ni kwamba miradi kadhaa inafanya kazi kwenye jukwaa lililojengwa kwenye DBMS hii. Mifumo ya ERP, ambazo zina maelfu ya vitendaji tofauti vya MATERIALIZED, vyenye maelfu ya watumiaji na hifadhidata za terabyte zenye mamia ya mamilioni ya rekodi zinazoendeshwa kwenye seva ya kawaida ya vichakataji viwili. Hata hivyo, mtu yeyote anaweza kuangalia/kukanusha ufanisi kwa kupakua jukwaa na PostgreSQL, kuwasha kukata maswali ya SQL na kujaribu kubadilisha mantiki na data hapo.

Katika makala zifuatazo, nitazungumzia pia jinsi unaweza kuweka vikwazo kwenye kazi, kufanya kazi na vikao vya mabadiliko, na mengi zaidi.

Chanzo: mapenzi.com

Kuongeza maoni