Balancing nyerat sareng maca dina pangkalan data

Dina saméméhna artikel Kuring digambarkeun konsép sarta palaksanaan database diwangun dina dasar fungsi, tinimbang tabel sarta widang sakumaha dina database relational. Éta nyayogikeun seueur conto anu nunjukkeun kaunggulan pendekatan ieu tibatan anu klasik. Loba kapanggih aranjeunna teu cukup ngayakinkeun.

Dina tulisan ieu, kuring bakal nunjukkeun kumaha konsép ieu ngamungkinkeun anjeun gancang sareng gampang nyaimbangkeun nyerat sareng maca kana pangkalan data tanpa aya parobahan dina logika operasi. fungsionalitas sarupa geus diusahakeun dilaksanakeun dina DBMS komérsial modern (khususna, Oracle jeung Microsoft SQL Server). Dina ahir tulisan kuring bakal nunjukkeun yén naon anu aranjeunna laksanakeun, sacara hampang, henteu hasil saé.

gambaran

Sapertos sateuacanna, pikeun pamahaman anu langkung saé kuring bakal ngamimitian pedaran kalayan conto. Sebutkeun urang kedah ngalaksanakeun logika anu bakal ngabalikeun daptar departemén kalayan jumlah karyawan sareng total gaji na.

Dina database fungsional bakal kasampak kawas kieu:

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


Pajeulitna ngalaksanakeun pamundut ieu dina DBMS mana waé bakal sami sareng O (jumlah karyawan)sabab itungan ieu merlukeun scanning sakabéh tabel karyawan lajeng ngagolongkeun aranjeunna dumasar departemén. Aya ogé bakal sababaraha leutik (kami yakin yén aya leuwih loba pagawé ti departemén) suplement gumantung kana rencana dipilih O (Jumlah karyawan) atawa O (jumlah departemén) keur golongan jeung sajabana.

Ieu jelas yén overhead palaksanaan bisa jadi béda dina DBMSs béda, tapi pajeulitna moal robah sagala cara.

Dina palaksanaan anu diusulkeun, DBMS fungsional bakal ngahasilkeun hiji subquery anu bakal ngitung nilai anu dipikabutuh pikeun jabatan, teras ngadamel JOIN sareng tabel jabatan pikeun kéngingkeun nami. Nanging, pikeun unggal fungsi, nalika nyatakeun, tiasa nyetél spidol MATERIALIZED khusus. Sistim bakal otomatis nyieun widang saluyu pikeun tiap fungsi misalna. Lamun ngarobah nilai fungsi hiji, nilai widang ogé bakal robah dina transaksi sarua. Nalika ngaksés pungsi ieu, médan anu tos diitung bakal diaksés.

Khususna, upami anjeun nyetél MATERIALIZED pikeun fungsi cacahan Karyawan и gajiSum, lajeng dua widang bakal ditambahkeun kana tabel kalawan daptar departemén, nu bakal nyimpen jumlah karyawan jeung total gaji maranéhanana. Iraha waé aya parobihan karyawan, gaji atanapi afiliasi jabatan, sistem bakal otomatis ngarobih nilai-nilai widang ieu. Paménta di luhur bakal ngakses widang ieu langsung tur bakal dieksekusi di O (jumlah departemén).

Naon larangan? Ngan hiji hal: fungsi ieu kudu boga jumlah kawates nilai input nu nilaina ditetepkeun. Upami teu kitu, mustahil pikeun ngawangun méja anu nyimpen sadaya nilaina, sabab moal aya méja kalayan jumlah barisan anu henteu terbatas.

contona:

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


Fungsi ieu didefinisikeun pikeun jumlah anu henteu terbatas tina nilai N (contona, naon waé nilai négatip anu cocog). Ku alatan éta, anjeun moal bisa nempatkeun MATERIALIZED dina eta. Janten ieu mangrupikeun watesan logis, sanés téknis (nyaéta, sanés kusabab urang henteu tiasa ngalaksanakeunana). Upami teu kitu, teu aya larangan. Anjeun tiasa make groupings, asihan, AND jeung ATAWA, PARTITION, recursion, jsb.

Contona, dina masalah 2.2 tina artikel saméméhna, anjeun tiasa nempatkeun MATERIALIZED dina duanana fungsi:

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;


Sistim sorangan bakal nyieun hiji méja kalayan kenop tipe langganan, barang и INTEGER, bakal nambahan dua widang ka dinya sarta bakal ngamutahirkeun nilai widang di antarana kalayan sagala parobahan. Nalika sauran salajengna ka fungsi ieu dilakukeun, aranjeunna moal diitung, tapi nilaina bakal dibaca tina widang anu saluyu.

Ngagunakeun mékanisme ieu, anjeun tiasa, contona, meunang leupas tina recursions (CTE) dina queries. Khususna, pertimbangkeun grup anu ngabentuk tangkal nganggo hubungan anak/indungna (unggal grup gaduh tautan ka indungna):

parent = DATA Group (Group);


Dina pangkalan data fungsional, logika rekursi tiasa ditetepkeun sapertos kieu:

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;


Kusabab pikeun fungsi nyaeta Kolot ditandaan MATERIALIZED, teras tabel sareng dua konci (grup) bakal didamel pikeun éta, dimana kolom nyaeta Kolot bakal bener ngan lamun konci kahiji anak kadua. Jumlah éntri dina tabel ieu bakal sarua jeung jumlah grup dikali rata jero tangkal. Upami anjeun peryogi, contona, pikeun ngitung jumlah turunan tina grup anu tangtu, anjeun tiasa nganggo fungsi ieu:

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


Moal aya CTE dina pamundut SQL. Gantina bakal aya GROUP BY basajan.

Ngagunakeun mékanisme ieu, anjeun ogé bisa kalayan gampang denormalize database lamun perlu:

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

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


Nalika nelepon hiji fungsi kaping pikeun garis urutan, widang nu aya indéks bakal dibaca tina tabel kalawan garis urutan. Nalika tanggal pesenan robih, sistem sorangan bakal otomatis ngitung deui tanggal denormalisasi dina jalur.

kaunggulan

Naon sakabéh mékanisme ieu? Dina DBMS klasik, tanpa nulis ulang patarosan, pamekar atanapi DBA ngan ukur tiasa ngarobih indéks, nangtukeun statistik sareng ngawartosan perencana pamundut kumaha ngaéksekusi aranjeunna (sareng petunjuk ngan ukur aya dina DBMS komérsial). Perkara teu sabaraha teuas maranéhna coba, aranjeunna moal bisa ngalengkepan query munggaran dina artikel di O (jumlah departemén) tanpa ngarobah queries atawa nambahkeun pemicu. Dina skéma anu diusulkeun, dina tahap pamekaran anjeun henteu kedah mikirkeun struktur panyimpen data sareng agrégasi anu dianggo. Sadaya ieu bisa gampang dirobah dina laleur, langsung di operasi.

Dina prakna eta Sigana mah ieu. Sababaraha urang ngamekarkeun logika langsung dumasar kana tugas di leungeun. Aranjeunna henteu ngartos algoritma sareng pajeulitna, rencana palaksanaan, jinis gabungan, atanapi komponén téknis anu sanés. Jalma-jalma ieu langkung seueur analis bisnis tibatan pamekar. Teras, sadaya ieu nuju kana tés atanapi operasi. Aktipkeun logging tina queries lila-ngajalankeun. Nalika query panjang dideteksi, lajeng jalma séjén (leuwih teknis - dasarna DBA) mutuskeun pikeun ngaktipkeun MATERIALIZED dina sababaraha fungsi panengah. Ieu ngalambatkeun ngarékam sakedik (sabab peryogi ngamutahirkeun widang tambahan dina transaksi). Sanajan kitu, teu ukur query ieu nyata speeded up, tapi ogé sakabeh batur anu ngagunakeun fungsi ieu. Dina waktos anu sami, mutuskeun fungsi mana anu bakal diwujudkeun kawilang gampang. Dua parameter utama: jumlah kamungkinan nilai input (ieu sabaraha rékaman bakal aya dina tabel pakait), sarta sabaraha sering eta dipaké dina fungsi séjén.

Analog

DBMS komérsial modern gaduh mékanisme anu sami: MATERIALIZED VIEW sareng FAST REFRESH (Oracle) sareng INDEXED VIEW (Microsoft SQL Server). Dina PostgreSQL, MATERIALIZED VIEW teu tiasa diropéa dina transaksi, tapi ngan ukur upami dipénta (komo sareng larangan anu ketat pisan), janten urang henteu nganggap éta. Tapi aranjeunna gaduh sababaraha masalah anu sacara signifikan ngabatesan panggunaanana.

Anu mimiti, anjeun ngan ukur tiasa ngaktifkeun materialisasi upami anjeun parantos nyiptakeun VIEW biasa. Upami teu kitu, anjeun bakal kudu nulis balik requests sésana pikeun ngakses pintonan anyar dijieun pikeun ngagunakeun materialization ieu. Atawa ninggalkeun sagalana sakumaha anu kasebut, tapi bakal sahenteuna teu epektip lamun aya tangtu data tos diitung, tapi loba queries teu salawasna make eta, tapi recalculate eta.

Kadua, aranjeunna gaduh sajumlah ageung larangan:

Oracle

5.3.8.4 Watesan Umum dina Refresh Gancang

Patarosan watesan pintonan materialized diwatesan saperti kieu:

• Pandangan anu diwujudkeun henteu kedah ngandung rujukan kana ekspresi anu henteu diulang sapertos SYSDATE jeung ROWNUM.
• Pandangan materialized teu kudu ngandung rujukan pikeun RAW or LONG RAW tipe data.
• Éta henteu tiasa ngandung a SELECT daptar subquery.
• Éta henteu tiasa ngandung fungsi analitis (contona, RANK) Dina SELECT klausa.
• Éta henteu tiasa ngarujuk kana méja dimana an XMLIndex indéks diartikeun.
• Éta henteu tiasa ngandung a MODEL klausa.
• Éta henteu tiasa ngandung a HAVING klausa kalawan subquery a.
• Teu bisa ngandung queries nested nu gaduh ANY, ALL, atawa NOT EXISTS.
• Éta henteu tiasa ngandung a [START WITH …] CONNECT BY klausa.
• Éta henteu tiasa ngandung sababaraha tabel rinci dina situs anu béda.
• ON COMMIT pintonan materialized teu tiasa gaduh tabel rinci jauh.
• Pamandangan materialized Nested kedah gaduh gabungan atanapi agrégat.
• Panémbong gabungan anu diwujudkeun sareng pintonan agrégat anu diwujudkeun kalayan a GROUP BY klausa teu bisa milih ti tabel indéks-diatur.

5.3.8.5 Watesan dina Refresh Gancang dina Témbongkeun Materialized kalawan Gabung wungkul

Nangtukeun patarosan pikeun pintonan materialized kalawan gabung wungkul tur euweuh aggregates boga larangan handap dina refresh gancang:

• Sadaya larangan ti «Watesan Umum dina Refresh Gancang".
• Aranjeunna teu tiasa gaduh GROUP BY klausa atawa agrégat.
• Rowids sadaya tabel di FROM daptar kudu muncul dina SELECT daptar query.
• Materialized view log kudu aya kalawan rowids pikeun sakabéh tabel dasar dina FROM daptar query.
• Anjeun teu bisa nyieun tempoan materialized gancang refreshable tina sababaraha tabel kalawan gabung basajan nu ngawengku hiji kolom tipe objék dina SELECT pernyataan.

Ogé, metode refresh anu anjeun pilih moal éfisién sacara optimal upami:

• Patarosan watesan ngagunakeun hiji gabung luar nu behaves kawas hiji gabung batin. Lamun pamundut watesan ngandung hiji gabung, mertimbangkeun nulis balik query watesan ngandung hiji gabung batin.
• nu SELECT daptar pintonan materialized ngandung ungkapan dina kolom ti sababaraha tabel.

5.3.8.6 Watesan dina Refresh Gancang dina Témbongkeun Materialized kalawan Aggregates

Nangtukeun patarosan pikeun pintonan materialized kalawan agrégat atawa gabung boga larangan handap dina refresh gancang:

• Sadaya larangan ti «Watesan Umum dina Refresh Gancang".

Refresh gancang dirojong pikeun duanana ON COMMIT jeung ON DEMAND pintonan materialized, tapi aya larangan handap:

• Sadaya tabel dina tampilan materialized kedah gaduh log view materialized, sareng log view materialized kedah:
  • Ngandung sagala kolom ti tabel referenced dina pintonan materialized.
  • Sebutkeun kalawan ROWID jeung INCLUDING NEW VALUES.
  • Sebutkeun SEQUENCE klausa lamun tabél diperkirakeun mangrupa campuran inserts / langsung-beban, ngahapus, sarta apdet.

• ngan SUM, COUNT, AVG, STDDEV, VARIANCE, MIN jeung MAX dirojong pikeun refresh gancang.
• COUNT(*) kudu dieusian.
• Fungsi agrégat kudu lumangsung ngan salaku bagian pangluarna éksprési. Hartina, agrégat saperti AVG(AVG(x)) or AVG(x)+ AVG(x) teu diwenangkeun.
• Pikeun unggal agrégat sapertos AVG(expr), nu pakait COUNT(expr) kudu hadir. Oracle nyarankeun éta SUM(expr) jadi dieusian.
• If VARIANCE(expr) or STDDEV(expr) ditangtukeun, COUNT(expr) jeung SUM(expr) kudu dieusian. Oracle nyarankeun éta SUM(expr *expr) jadi dieusian.
• nu SELECT kolom dina query watesan teu bisa mangrupa éksprési kompléks jeung kolom ti sababaraha tabel dasar. A workaround mungkin mun ieu ngagunakeun pintonan materialized nested.
• nu SELECT daftar kudu ngandung sakabéh GROUP BY kolom.
• Témbongkeun materialized henteu dumasar kana hiji atawa leuwih tabel jauh.
• Upami anjeun nganggo a CHAR tipe data dina kolom filter tina log tempoan materialized, susunan karakter situs master sarta pintonan materialized kudu sarua.
• Lamun pintonan materialized boga salah sahiji di handap, lajeng refresh gancang dirojong ukur dina inserts DML konvensional sarta beban langsung.
  • pintonan materialized kalawan MIN or MAX agrégat
  • Pandangan materialized anu gaduh SUM(expr) tapi henteu COUNT(expr)
  • pintonan materialized tanpa COUNT(*)

  Pandangan materialisasi sapertos kitu disebut pandangan anu diwujudkeun ukur sisipan.

• Hiji pintonan materialized kalawan MAX or MIN nyaeta gancang refreshable sanggeus ngahapus atawa dicampur pernyataan DML lamun teu boga WHERE klausa.
  Refresh gancang max / mnt saatos ngahapus atanapi dicampur DML henteu gaduh paripolah anu sami sareng kasus sisipan wungkul. Éta ngahapus sareng ngitung deui nilai max / mnt pikeun grup anu kapangaruhan. Anjeun kudu sadar dampak kinerja na.
• Pamandangan materialized kalawan pintonan ngaranna atawa subqueries dina FROM klausa bisa gancang refreshed disadiakeun pintonan bisa sagemblengna ngahiji. Kanggo inpo nu mana pintonan bakal ngagabung, tingali Oracle Database SQL Rujukan Basa.
• Upami teu aya gabungan luar, anjeun tiasa gaduh pilihan sawenang sareng gabung dina WHERE klausa.
• Pamandangan agrégat materialized kalawan gabung luar gancang refreshable sanggeus DML konvensional sarta beban langsung, disadiakeun ngan tabel luar geus dirobah. Ogé, konstrain unik kedah aya dina kolom gabung dina tabel gabung batin. Mun aya ngagabung luar, sakabeh ngagabung kudu disambungkeun ku ANDs sareng kedah nganggo persamaan (=) operator.
• Pikeun pintonan materialized kalawan CUBE, ROLLUP, set grouping, atawa concatenation sahijina, larangan handap lumaku:
  • nu SELECT Daptar kudu ngandung distinguisher grouping nu bisa boh mangrupa GROUPING_ID fungsi dina sakabéh GROUP BY babasan atawa GROUPING fungsi hiji pikeun tiap GROUP BY éksprési. Contona, upami nu GROUP BY klausa tina pintonan materialized nyaeta "GROUP BY CUBE(a, b)", lajeng SELECT daptar kedah ngandung boh "GROUPING_ID(a, b)"atawa"GROUPING(a) AND GROUPING(b)» pikeun pintonan materialized janten gancang refreshable.
  • GROUP BY teu kudu ngahasilkeun sagala duplikat groupings. Salaku conto, "GROUP BY a, ROLLUP(a, b)"teu gancang refreshable sabab ngahasilkeun duplikat groupings"(a), (a, b), AND (a)".

5.3.8.7 Watesan dina Fast Refresh on Materialized Views kalawan UNION ALL

Pamandangan materialized kalawan UNION ALL set operator rojongan nu REFRESH FAST pilihan lamun kaayaan di handap ieu nyugemakeun:

• Patarosan watesan kedah gaduh UNION ALL operator di tingkat luhur.

  nu UNION ALL operator teu bisa diasupkeun kana subquery a, kalawan hiji iwal: The UNION ALL tiasa di subquery di FROM klausa disadiakeun query watesan nyaeta tina formulir SELECT * FROM (view atanapi subquery kalawan UNION ALL) saperti dina conto di handap ieu:

  Jieun VIEW view_with_unionall AS
  (PILIH c.rowid crid, c.cust_id, 2 umarker
   TI nasabah c WHERE c.cust_last_name = 'Smith'
   UNION ALL
   PILIH c.rowid crid, c.cust_id, 3 umarker
   TI nasabah c WHERE c.cust_last_name = 'Jones');
  
  Jieun Témbongkeun Materialized unionall_inside_view_mv
  Nyegerkeun gancang dina paménta AS
  PILIH * TI view_with_unionall;
  

  Catet yén pintonan view_with_unionall satisfies sarat pikeun refresh gancang.

• Unggal blok query dina UNION ALL query kudu nyugemakeun sarat tina tempoan materialized refreshable gancang jeung aggregates atawa tempoan materialized refreshable gancang jeung ngagabung.

  Log view materialized luyu kudu dijieun dina tabel sakumaha diperlukeun pikeun tipe pakait tina tempoan materialized refreshable gancang.
  Catet yén Oracle databés ogé ngamungkinkeun kasus husus tina tabel tunggal materialized view kalawan ngagabung ngan disadiakeun dina ROWID kolom geus kaasup kana SELECT daftar na dina log view materialized. Ieu dipidangkeun dina query watesan pintonan view_with_unionall.

• nu SELECT daptar unggal query kedah ngawengku a UNION ALL spidol, jeung UNION ALL kolom kudu boga numerik konstanta béda atawa nilai string dina unggal UNION ALL dahan. Salajengna, kolom spidol kudu muncul dina posisi ordinal sarua dina SELECT daptar unggal blok query. Tingali"UNION ALL spidol jeung Query Rewrite»kanggo inpormasi langkung lengkep ihwal UNION ALL spidol.
• Sababaraha fitur sapertos gabungan luar, kueri panempoan agrégat agrégat wungkul sareng tabel jauh teu dirojong pikeun pintonan materialized kalayan UNION ALL. Catet, kumaha oge, yén pintonan materialized dipaké dina réplikasi, nu teu ngandung gabung atawa aggregates, bisa gancang refreshed lamun UNION ALL atawa tabel jauh dipaké.
• Parameter initialization kasaluyuan kudu disetel ka 9.2.0 atawa saluhureuna pikeun nyieun tempoan materialized refreshable gancang jeung UNION ALL.

Kuring teu hayang nyigeung fans Oracle, tapi ditilik ku daptar larangan maranéhanana, sigana mékanisme ieu ditulis teu dina kasus umum, ngagunakeun sababaraha jenis model, tapi ku rébuan India, dimana dulur dibere kasempetan pikeun. Tulis cabangna masing-masing, masing-masing ngalakukeun naon anu anjeunna tiasa dilakukeun. Ngagunakeun mékanisme ieu logika nyata kawas leumpang ngaliwatan minefield a. Anjeun tiasa kéngingkeun tambang iraha waé ku cara pencét salah sahiji larangan anu teu jelas. Kumaha gawéna ogé patarosan misah, tapi éta saluareun ruang lingkup artikel ieu.

Microsoft SQL Server

Syarat tambahan

Salian pilihan SET sareng sarat fungsi deterministik, sarat di handap ieu kedah nyumponan:

• Pamaké anu ngaéksekusi CREATE INDEX kudu boga pintonan.
• Lamun anjeun nyieun indéks dina, nu IGNORE_DUP_KEY pilihan kudu disetel ka OFF (setting standar).
• Tabél kedah dirujuk ku nami dua bagian, schema.tablename dina harti pintonan.
• Fungsi anu ditetepkeun ku pangguna anu dirujuk dina tampilan kedah didamel ku cara nganggo WITH SCHEMABINDING pilihan.
• Sakur fungsi anu ditetepkeun ku pangguna anu dirujuk dina tampilan kedah dirujuk ku nami dua bagian, ..
• Harta aksés data tina hiji fungsi-diartikeun pamaké kudu NO SQL, jeung harta aksés éksternal kudu NO.
• Fungsi runtime basa umum (CLR) bisa muncul dina daptar pilih pintonan, tapi teu bisa jadi bagian tina harti konci indéks clustered. Fungsi CLR teu bisa muncul dina klausa WHERE pintonan atawa klausa ON operasi JOIN dina pintonan.
• Fungsi CLR jeung métode tipe CLR-diartikeun pamaké dipaké dina definisi view kudu boga sipat diatur sakumaha ditémbongkeun dina tabel di handap ieu.

  sipat
  Catetan

  DETERMINISTIK = BENER
  Kudu dinyatakeun sacara eksplisit salaku atribut metodeu Microsoft .NET Framework.

  PRESISI = BENER
  Kudu dinyatakeun sacara eksplisit salaku atribut metodeu .NET Framework.

  AKSES DATA = NO SQL
  Ditangtukeun ku netepkeun atribut DataAccess ka DataAccessKind.None sareng atribut SystemDataAccess ka SystemDataAccessKind.None.

  AKSES LUAR = NO
  Sipat ieu ingkar kana NO pikeun rutinitas CLR.

• Panempoan kedah diciptakeun ku ngagunakeun WITH SCHEMABINDING pilihan.
• Panempoan kedah ngan ukur ngarujuk kana tabel dasar anu aya dina database anu sami sareng tampilan. Panempoan teu tiasa ngarujuk kana pandangan anu sanés.
• Pernyataan SELECT dina definisi view henteu kedah ngandung unsur Transact-SQL di handap ieu:

  COUNT
  fungsi ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, JEUNG OPENXML)
  OUTER ngagabung (LEFT, RIGHT, atawa FULL)

  Tabel turunan (ditetepkeun ku nangtukeun a SELECT pernyataan dina FROM klausa)
  Ngagabung sorangan
  Nangtukeun kolom ku ngagunakeun SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARP, atawa AVG
  Éksprési méja umum (CTE)

  ngambang1, naskah, téks, gambaran, XML, atawa filestream kolom
  Subkueri
  OVER klausa, nu ngawengku ranking atawa agrégat fungsi jandela

  Predikat téks lengkep (CONTAINS, FREETEXT)
  SUM fungsi anu ngarujuk kana ekspresi nullable
  ORDER BY

  Fungsi agrégat anu ditetepkeun ku pangguna CLR
  TOP
CUBE, ROLLUP, atawa GROUPING SETS operator

  MIN, MAX
UNION, EXCEPT, atawa INTERSECT operator
  TABLESAMPLE

  variabel tabel
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  Susunan kolom jarang
  Inline (TVF) atanapi multi-statement table-valued functions (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 Panempoan indéks bisa ngandung ngambang kolom; kumaha oge, kolom misalna teu bisa kaasup kana konci indéks clustered.

• If GROUP BY hadir, harti VIEW kudu ngandung COUNT_BIG(*) jeung teu kudu ngandung HAVING. ieu GROUP BY larangan anu lumaku ngan pikeun harti pintonan indéks. Paménta tiasa nganggo pandangan anu diindeks dina rencana palaksanaan na sanaos henteu nyugemakeun ieu GROUP BY pangwatesan.
• Lamun harti view ngandung a GROUP BY klausa, konci indéks clustered unik bisa nuduhkeun ukur kolom dieusian dina GROUP BY klausa.

Jelas di dieu yén urang India henteu aub, sabab mutuskeun pikeun ngalakukeunana dumasar kana skéma "urang bakal ngalakukeun sakedik, tapi saé." Nyaéta, aranjeunna gaduh langkung seueur tambang di lapangan, tapi lokasina langkung transparan. Hal anu paling nguciwakeun nyaéta watesan ieu:

Panempoan kedah ngan ukur ngarujuk kana tabel dasar anu aya dina database anu sami sareng tampilan. Panempoan teu tiasa ngarujuk kana pandangan anu sanés.

Dina terminologi urang, ieu ngandung harti yén hiji fungsi teu bisa ngakses fungsi materialized sejen. Ieu ngirangan sadaya ideologi dina pucukna.
Ogé, watesan ieu (sareng salajengna dina téks) ngirangan pisan kasus pamakean:

Pernyataan SELECT dina definisi view henteu kedah ngandung unsur Transact-SQL di handap ieu:

COUNT
fungsi ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, JEUNG OPENXML)
OUTER ngagabung (LEFT, RIGHT, atawa FULL)

Tabel turunan (ditetepkeun ku nangtukeun a SELECT pernyataan dina FROM klausa)
Ngagabung sorangan
Nangtukeun kolom ku ngagunakeun SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, atawa AVG
Éksprési méja umum (CTE)

ngambang1, naskah, téks, gambaran, XML, atawa filestream kolom
Subkueri
OVER klausa, nu ngawengku ranking atawa agrégat fungsi jandela

Predikat téks lengkep (CONTAINS, FREETEXT)
SUM fungsi anu ngarujuk kana ekspresi nullable
ORDER BY

Fungsi agrégat anu ditetepkeun ku pangguna CLR
TOP
CUBE, ROLLUP, atawa GROUPING SETS operator

MIN, MAX
UNION, EXCEPT, atawa INTERSECT operator
TABLESAMPLE

variabel tabel
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Susunan kolom jarang
Inline (TVF) atanapi multi-statement table-valued functions (MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOIN, UNION, ORDER BY sareng anu sanésna dilarang. Bisa jadi leuwih gampang pikeun nangtukeun naon nu bisa dipaké tinimbang nu teu bisa dipaké. Daptar meureun bakal leuwih leutik.

Pikeun nyimpulkeun: set badag tina larangan dina unggal (hayu urang catetan komérsial) DBMS vs euweuh (iwal hiji logis, teu teknis) dina téhnologi LGPL. Sanajan kitu, eta kudu dicatet yén ngalaksanakeun mékanisme ieu dina logika relational rada leuwih hese tibatan dina logika fungsi digambarkeun.

Реализация

Kumaha gawéna? PostgreSQL dianggo salaku "mesin virtual". Aya hiji algoritma kompléks di jero nu ngawangun queries. Ieuh sumber. Sareng henteu ngan ukur sakumpulan heuristik anu ageung sareng sakumpulan upami. Janten, upami anjeun gaduh sababaraha bulan pikeun diajar, anjeun tiasa nyobian ngartos arsitektur.

Naha éta tiasa dianggo sacara efektif? Lumayan efektif. Hanjakal, ieu téh hésé ngabuktikeun. Kuring ukur bisa disebutkeun yen lamun nganggap rébuan queries nu aya dina aplikasi badag, lajeng rata-rata aranjeunna leuwih efisien ti developer alus. Hiji programmer SQL unggulan bisa nulis query sagala leuwih éfisién, tapi kalawan sarébu queries anjeunna ngan saukur moal boga motivasi atawa waktu pikeun ngalakukeunana. Hiji-hijina hal anu ayeuna kuring tiasa disebatkeun salaku bukti efektivitas nyaéta sababaraha proyék anu damel dina platform anu diwangun dina DBMS ieu. Sistem ERP, nu boga rébuan fungsi MATERIALIZED béda, kalawan rébuan pamaké sarta database terabyte kalawan ratusan juta rékaman ngajalankeun dina server dua-processor biasa. Nanging, saha waé tiasa mariksa / ngabantah éféktivitasna ku ngaunduh platform sareng PostgreSQL, ngahurungkeun logging queries SQL jeung nyoba ngarobah logika jeung data aya.

Dina tulisan di handap ieu, kuring ogé bakal ngobrol ngeunaan kumaha anjeun tiasa nyetél larangan dina fungsi, damel sareng sesi parobihan, sareng seueur deui.

sumber: www.habr.com