Balancing nulis lan maca ing database

Ing sadurunge artikel Aku diterangake konsep lan implementasine saka database dibangun ing basis saka fungsi, tinimbang tabel lan lapangan kaya ing database hubungan. Iki nyedhiyakake akeh conto sing nuduhake kaluwihan pendekatan iki tinimbang sing klasik. Akeh sing nemokake dheweke ora cukup ngyakinake.

Ing artikel iki, aku bakal nuduhake kepiye konsep iki ngidini sampeyan kanthi cepet lan gampang ngimbangi nulis lan maca menyang database tanpa owah-owahan ing logika operasi. Fungsi sing padha wis dicoba ditindakake ing DBMS komersial modern (utamane, Oracle lan Microsoft SQL Server). Ing pungkasan artikel aku bakal nuduhake yen apa sing ditindakake, kanthi gampang, ora bisa ditindakake kanthi becik.

Description

Kaya sadurunge, kanggo pangerten sing luwih apik, aku bakal miwiti deskripsi kanthi conto. Ayo kita kudu ngetrapake logika sing bakal ngasilake dhaptar departemen kanthi jumlah karyawan lan gaji total.

Ing basis data fungsional bakal katon kaya iki:

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


Kerumitan nglakokake pitakon iki ing DBMS apa wae bakal padha karo O (jumlah karyawan)amarga pitungan iki mbutuhake mindhai kabeh tabel karyawan banjur dikelompokake miturut departemen. Ana uga sawetara cilik (kita pitados bilih ana luwih akeh karyawan saka departemen) tambahan gumantung ing rencana milih O (jumlah karyawan) utawa O (jumlah departemen) kanggo klompok lan liya-liyane.

Cetha yen overhead eksekusi bisa uga beda-beda ing DBMS sing beda, nanging kerumitan ora bakal owah kanthi cara apa wae.

Ing implementasine sing diusulake, DBMS fungsional bakal ngasilake siji subquery sing bakal ngetung nilai sing dibutuhake kanggo departemen kasebut, banjur nggawe JOIN karo tabel departemen kanggo entuk jeneng kasebut. Nanging, kanggo saben fungsi, nalika ngumumake, bisa nyetel marker MATERIALIZED khusus. Sistem bakal kanthi otomatis nggawe kolom sing cocog kanggo saben fungsi kasebut. Nalika ngganti Nilai saka fungsi, Nilai saka lapangan uga bakal ngganti ing transaksi padha. Nalika ngakses fungsi iki, kolom sing wis diwilang bakal diakses.

Utamane, yen sampeyan nyetel MATERIALIZED kanggo fungsi cacahe Karyawan и gajiSum, banjur rong lapangan bakal ditambahake ing meja kanthi dhaptar departemen, sing bakal nyimpen jumlah karyawan lan gaji total. Yen ana owah-owahan karyawan, gaji utawa afiliasi departemen, sistem kasebut kanthi otomatis ngganti nilai lapangan kasebut. Pitakon ing ndhuwur bakal ngakses kolom kasebut langsung lan bakal dieksekusi ing O (jumlah departemen).

Apa sing watesan? Mung siji: fungsi kasebut kudu duwe sawetara nilai input sing ditemtokake. Yen ora, bakal ora bisa mbangun tabel sing nyimpen kabeh nilai, amarga ora ana tabel kanthi jumlah baris tanpa wates.

Conto:

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


Fungsi iki ditetepake kanggo nomer tanpa wates saka nilai N (contone, sembarang nilai negatif cocok). Mulane, sampeyan ora bisa sijine MATERIALIZED ing. Dadi iki minangka watesan logis, dudu teknis (yaiku, ora amarga ora bisa ngetrapake). Yen ora, ora ana watesan. Sampeyan bisa nggunakake klompok, ngurutake, AND lan UTAWA, PARTITION, rekursi, lsp.

Contone, ing masalah 2.2 saka artikel sadurunge, sampeyan bisa sijine MATERIALIZED ing loro 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;


Sistem kasebut dhewe bakal nggawe siji tabel kanthi tombol jinis customer, Product и ONGKO, bakal nambah rong kolom lan bakal nganyari nilai lapangan kasebut kanthi owah-owahan. Nalika telpon luwih lanjut kanggo fungsi kasebut, ora bakal diwilang, nanging nilai kasebut bakal diwaca saka kolom sing cocog.

Nggunakake mekanisme iki, sampeyan bisa, contone, nyisihaken saka recursions (CTE) ing pitakonan. Utamane, nimbang klompok sing mbentuk wit nggunakake hubungan anak / wong tuwa (saben klompok duwe pranala menyang wong tuwane):

parent = DATA Group (Group);


Ing basis data fungsional, logika rekursi bisa ditemtokake kaya ing ngisor iki:

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;


Wiwit kanggo fungsi punikaParent ditandhani MATERIALIZED, banjur tabel karo rong tombol (grup) bakal digawe kanggo iku, kang kolom punikaParent bakal bener mung yen tombol pisanan iku anak saka kaloro. Jumlah entri ing tabel iki bakal padha karo jumlah klompok dikalikan karo ambane rata-rata wit. Yen sampeyan perlu, contone, kanggo ngetung jumlah turunan saka klompok tartamtu, sampeyan bisa nggunakake fungsi iki:

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


Ora bakal ana CTE ing query SQL. Nanging bakal ana GROUP BY prasaja.

Nggunakake mekanisme iki, sampeyan uga bisa gampang denormalize database yen perlu:

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

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


Nalika nelpon fungsi tanggal kanggo baris pesenan, lapangan sing ana indeks bakal diwaca saka meja karo baris pesenan. Nalika tanggal pesenan diganti, sistem kasebut kanthi otomatis ngetung tanggal denormalisasi ing baris kasebut.

Keuntungan

Apa kabeh mekanisme iki? Ing DBMS klasik, tanpa nulis ulang pitakon, pangembang utawa DBA mung bisa ngganti indeks, nemtokake statistik lan ngandhani perancang pitakon babagan carane nglakokake (lan Petunjuk mung kasedhiya ing DBMS komersial). Ora ketompo carane hard padha nyoba, padha ora bakal bisa ngrampungake pitakonan pisanan ing artikel ing O (jumlah departemen) tanpa ngganti pitakon utawa nambah pemicu. Ing skema sing diusulake, ing tahap pangembangan sampeyan ora kudu mikir babagan struktur panyimpenan data lan agregasi sing digunakake. Kabeh iki bisa gampang diganti ing fly, langsung ing operasi.

Ing laku katon kaya iki. Sawetara wong ngembangake logika langsung adhedhasar tugas sing ditindakake. Dheweke ora ngerti algoritma lan kerumitan, utawa rencana eksekusi, utawa jinis gabungan, utawa komponen teknis liyane. Wong-wong iki luwih akeh analis bisnis tinimbang pangembang. Banjur, kabeh iki dadi testing utawa operasi. Mbisakake logging pitakon sing wis suwe. Nalika pitakon dawa dideteksi, banjur wong liya (luwih teknis - ateges DBA) mutusake kanggo ngaktifake MATERIALIZED ing sawetara fungsi penengah. Iki slows mudhun rekaman sethitik (amarga mbutuhake nganyari lapangan tambahan ing transaksi). Nanging, ora mung pitakon iki sing cepet banget, nanging uga kabeh liyane sing nggunakake fungsi iki. Ing wektu sing padha, mutusake fungsi sing bakal diwujudake relatif gampang. Rong paramèter utama: jumlah nilai input sing bisa (iki jumlah cathetan ing tabel sing cocog), lan sepira kerepe digunakake ing fungsi liyane.

Analog

DBMS komersial modern duwe mekanisme sing padha: MATERIALIZED VIEW karo FAST REFRESH (Oracle) lan INDEXED VIEW (Microsoft SQL Server). Ing PostgreSQL, MATERIALIZED VIEW ora bisa dianyari ing transaksi, nanging mung ing panyuwunan (lan malah karo watesan banget ketat), supaya kita ora nimbang iku. Nanging dheweke duwe sawetara masalah sing mbatesi panggunaane.

Kaping pisanan, sampeyan mung bisa ngaktifake materialisasi yen sampeyan wis nggawe VIEW biasa. Yen ora, sampeyan kudu nulis maneh panjalukan sing isih ana kanggo ngakses tampilan sing mentas digawe kanggo nggunakake materialisasi iki. Utawa ninggalake kabeh minangka, nanging bakal paling ora efektif yen ana tartamtu wis data wis diwilang, nanging akeh pitakonan ora tansah nggunakake, nanging recalculate iku.

Kapindho, dheweke duwe akeh larangan:

Oracle

5.3.8.4 Watesan Umum kanggo Refresh Cepet

Pitakonan sing nemtokake tampilan materialisasi diwatesi kaya ing ngisor iki:

• Tampilan sing diwujudake kudu ora ngemot referensi kanggo ekspresi non-baleni kaya SYSDATE lan ROWNUM.
• Tampilan materialized kudu ora ngemot referensi kanggo RAW or LONG RAW jinis data.
• Ora bisa ngemot a SELECT dhaptar subquery.
• Ora bisa ngemot fungsi analitis (contone, RANK) ing SELECT klausa.
• Ora bisa ngrujuk tabel ing ngendi an XMLIndex indeks ditetepake.
• Ora bisa ngemot a MODEL klausa.
• Ora bisa ngemot a HAVING klausa karo subquery.
• Ora bisa ngemot pitakon nested sing duwe ANY, ALL, utawa NOT EXISTS.
• Ora bisa ngemot a [START WITH …] CONNECT BY klausa.
• Ora bisa ngemot macem-macem tabel rinci ing macem-macem situs.
• ON COMMIT views materialized ora bisa duwe tabel rinci remot.
• Tampilan sing diwujudake kudu duwe gabungan utawa agregat.
• Tampilan gabungan materialized lan tampilan agregat materialized kanthi a GROUP BY klausa ora bisa milih saka tabel indeks-diatur.

5.3.8.5 Watesan kanggo Refresh Cepet ing Tampilan Materialized karo Gabung Mung

Nemtokake pitakon kanggo tampilan sing diwujudake kanthi gabung lan ora ana agregat duwe watesan ing ngisor iki babagan refresh cepet:

• Kabeh larangan saka «Watesan Umum ing Refresh Cepet".
• Dheweke ora bisa duwe GROUP BY klausa utawa agregat.
• Rowids kabeh tabel ing FROM dhaftar kudu katon ing SELECT dhaptar pitakon.
• Log tampilan materialized kudu ana karo rowids kanggo kabeh tabel dhasar ing FROM dhaptar pitakon.
• Sampeyan ora bisa nggawe tampilan materialized cepet refreshable saka macem-macem tabel karo gabungan prasaja sing kalebu kolom jinis obyek ing SELECT statement.

Uga, cara refresh sing sampeyan pilih ora bakal efisien kanthi optimal yen:

• Pitakon sing nemtokake nggunakake gabungan njaba sing tumindak kaya gabungan njero. Yen pitakonan sing nemtokake ngemot gabungan kasebut, coba nulis maneh pitakon sing nemtokake kanggo ngemot gabungan batin.
• The SELECT dhaptar tampilan materialized ngemot ekspresi ing kolom saka pirang-pirang tabel.

5.3.8.6 Watesan kanggo Refresh Cepet ing Tampilan Materialized karo Agregat

Nemtokake pitakon kanggo tampilan sing diwujudake kanthi agregat utawa gabungan duwe watesan ing ngisor iki babagan refresh cepet:

• Kabeh larangan saka «Watesan Umum ing Refresh Cepet".

Cepet refresh didhukung kanggo loro ON COMMIT lan ON DEMAND tampilan materialized, nanging watesan ing ngisor iki ditrapake:

• Kabeh tabel ing tampilan materialisasi kudu duwe log tampilan materialized, lan log tampilan materialized kudu:
  • Isi kabeh kolom saka tabel sing dirujuk ing tampilan materialized.
  • Nemtokake karo ROWID lan INCLUDING NEW VALUES.
  • Nemtokake SEQUENCE klausa yen tabel samesthine duwe campuran sisipan / langsung-muat, mbusak, lan nganyari.

• mung SUM, COUNT, AVG, STDDEV, VARIANCE, MIN lan MAX didhukung kanggo refresh cepet.
• COUNT(*) kudu ditemtokake.
• Fungsi agregat kudu kedadeyan mung minangka bagéan paling njaba saka ekspresi. Sing, aggregates kayata AVG(AVG(x)) or AVG(x)+ AVG(x) ora diidini.
• Kanggo saben agregat kayata AVG(expr), sing cocog COUNT(expr) kudu ana. Oracle nyaranake SUM(expr) ditemtokake.
• If VARIANCE(expr) or STDDEV(expr) ditemtokake, COUNT(expr) lan SUM(expr) kudu ditemtokake. Oracle nyaranake SUM(expr *expr) ditemtokake.
• The SELECT kolom ing pitakonan sing nemtokake ora bisa dadi ekspresi kompleks kanthi kolom saka pirang-pirang tabel dhasar. Solusi sing bisa ditindakake yaiku nggunakake tampilan materialized nested.
• The SELECT dhaftar kudu ngemot kabeh GROUP BY kolom.
• Tampilan materialized ora adhedhasar siji utawa luwih tabel remot.
• Yen sampeyan nggunakake a CHAR jinis data ing kolom Filter saka log tampilan materialized, set karakter saka situs master lan tampilan materialized kudu padha.
• Yen tampilan materialized duwe salah siji saka ing ngisor iki, banjur refresh cepet didhukung mung ing sisipan DML conventional lan kathah langsung.
  • views materialized karo MIN or MAX agregat
  • Pandangan materialized sing duwe SUM(expr) nanging ora COUNT(expr)
  • Tampilan materialized tanpa COUNT(*)

  Pandangan materialisasi kasebut diarani tampilan mung sisipan.

• A tampilan materialized karo MAX or MIN cepet refreshable sawise mbusak utawa campuran DML statements yen ora duwe WHERE klausa.
  Refresh cepet maks / min sawise mbusak utawa dicampur DML ora duwe prilaku sing padha karo kasus insert-mung. Mbusak lan ngitung maneh nilai maksimal / min kanggo klompok sing kena pengaruh. Sampeyan kudu ngerti impact kinerja sawijining.
• Tampilan materialized kanthi jeneng tampilan utawa subqueries ing FROM klausa bisa dianyari kanthi cepet yen tampilan bisa digabung kanthi lengkap. Kanggo informasi babagan tampilan sing bakal digabung, waca Oracle Database SQL Language Referensi.
• Yen ora ana gabungan njaba, sampeyan bisa uga duwe pilihan sewenang-wenang lan gabung ing WHERE klausa.
• Tampilan agregat sing diwujudake kanthi gabungan njaba bisa diresiki kanthi cepet sawise DML konvensional lan beban langsung, yen mung tabel njaba sing wis diowahi. Uga, watesan unik kudu ana ing kolom gabungan ing tabel gabungan njero. Yen ana gabungan njaba, kabeh gabungan kudu disambungake ANDs lan kudu nggunakake kesetaraan (=) operator.
• Kanggo views materialized karo CUBE, ROLLUP, klompok, utawa gabungan, watesan ing ngisor iki ditrapake:
  • The SELECT dhaftar kudu ngemot klompok distinguisher sing bisa salah siji a GROUPING_ID fungsi ing kabeh GROUP BY ungkapan utawa GROUPING fungsi siji kanggo saben GROUP BY ekspresi. Contone, yen ing GROUP BY klausa saka tampilan materialisasi yaiku "GROUP BY CUBE(a, b)", banjur SELECT dhaptar kudu ngemot salah siji "GROUPING_ID(a, b)"utawa"GROUPING(a) AND GROUPING(b)»kanggo tampilan materialized supaya cepet refreshable.
  • GROUP BY ngirim ora nyebabake panglompokan duplikat. Tuladhane, "GROUP BY a, ROLLUP(a, b)"Ora cepet refreshable amarga ngasilake duplikat klompok"(a), (a, b), AND (a)".

5.3.8.7 Watesan kanggo Refresh Cepet ing Tampilan Materialized karo UNION ALL

Tampilan materialized karo UNION ALL nyetel operator ndhukung ing REFRESH FAST pilihan yen kondisi ing ngisor iki kapenuhan:

• Pitakon sing nemtokake kudu duwe UNION ALL operator ing tingkat ndhuwur.

  The UNION ALL operator ora bisa ditempelake ing subquery, karo siji pangecualian: The UNION ALL bisa ing subquery ing FROM klausa sing diwenehake pitakon sing nemtokake yaiku wujud SELECT * FROM (ndeleng utawa subquery karo UNION ALL) kaya ing conto ing ngisor iki:

  Gawe VIEW view_with_unionall AS (PILIH c.rowid crid, c.cust_id, 2 umarker saka pelanggan c WHERE c.cust_last_name = 'Smith' UNION ALL PILIH c.rowid crid, c.cust_id, 3 umarker FROM pelanggan c WHERE c.cust_last_name 'Jones'); Gawe VIEW MATERIALIZED unionall_inside_view_mv REFRESH CEPAT ON DEMAND AS PILIH * Saka view_with_unionall;
  

  Elinga yen tampilan view_with_unionall nyukupi syarat kanggo refresh cepet.

• Saben blok query ing UNION ALL pitakon kudu nyukupi syarat tampilan materialisasi sing bisa dianyari kanthi agregat utawa tampilan sing bisa dideleng kanthi cepet kanthi gabung.

  Log tampilan materialized cocok kudu digawe ing tabel minangka dibutuhake kanggo jinis cocog tampilan materialized cepet refreshable.
  Elinga yen Oracle Database uga ngidini kasus khusus saka tampilan tabel siji materialized karo gabung mung kasedhiya ing ROWID kolom wis klebu ing SELECT dhaptar lan ing log tampilan materialized. Iki ditampilake ing pitakonan sing nemtokake tampilan view_with_unionall.

• The SELECT dhaftar saben pitakonan kudu kalebu a UNION ALL tandha, lan UNION ALL kolom kudu duwe nilai numerik konstan utawa string ing saben UNION ALL cabang. Salajengipun, kolom panandha kudu katon ing posisi ordinal padha ing SELECT dhaptar saben blok query. Deleng"UNION ALL Marker lan Query Rewrite»kanggo informasi luwih lengkap babagan UNION ALL spidol.
• Sawetara fitur kayata gabungan njaba, pitakon tampilan agregat sing diwujudake mung sisipan lan tabel remot ora didhukung kanggo tampilan sing diwujudake kanthi UNION ALL. Elinga, yen tampilan materialisasi sing digunakake ing replikasi, sing ora ngemot gabungan utawa agregat, bisa dianyari kanthi cepet nalika UNION ALL utawa tabel remot digunakake.
• Parameter inisialisasi kompatibilitas kudu disetel menyang 9.2.0 utawa sing luwih dhuwur kanggo nggawe tampilan materialisasi sing bisa dianyari kanthi cepet. UNION ALL.

Aku ora pengin nyinggung pembuangan Oracle, nanging menehi kritik dening dhaptar watesan, misale jek sing mekanisme iki ditulis ora ing kasus umum, nggunakake sawetara jinis model, nanging dening ewu India, ngendi saben wong diwenehi kesempatan kanggo. nulis cabangé dhéwé-dhéwé, lan saben-saben padha nindakaké apa kang bisa dilakoni. Nggunakake mekanisme iki kanggo logika nyata kaya mlaku liwat ranjau. Sampeyan bisa entuk tambang kapan wae kanthi mencet salah sawijining larangan sing ora jelas. Cara kerjane uga minangka pitakonan sing kapisah, nanging ngluwihi ruang lingkup artikel iki.

Server Microsoft SQL

Syarat Tambahan

Saliyane opsi SET lan syarat fungsi deterministik, syarat ing ngisor iki kudu dipenuhi:

• Pangguna sing nglakokake CREATE INDEX kudu dadi pemilik tampilan.
• Nalika sampeyan nggawe indeks, ing IGNORE_DUP_KEY pilihan kudu disetel kanggo OFF (setelan gawan).
• Tabel kudu dirujuk kanthi jeneng rong bagean, rencana.jeneng tabel ing definisi tampilan.
• Fungsi sing ditetepake pangguna sing dirujuk ing tampilan kudu digawe kanthi nggunakake WITH SCHEMABINDING pilihan.
• Sembarang fungsi sing ditetepake pangguna sing dirujuk ing tampilan kudu dirujuk nganggo jeneng rong bagean, ..
• Properti akses data saka fungsi sing ditemtokake pangguna kudu NO SQL, lan properti akses eksternal kudu NO.
• Fungsi runtime basa umum (CLR) bisa katon ing dhaptar pilih saka tampilan, nanging ora bisa dadi bagéan saka definisi tombol indeks clustered. Fungsi CLR ora bisa katon ing klausa WHERE tampilan utawa klausa ON operasi JOIN ing tampilan.
• Fungsi lan metode CLR saka jinis sing ditemtokake pangguna CLR sing digunakake ing definisi tampilan kudu nduweni sifat sing disetel kaya sing dituduhake ing tabel ing ngisor iki.

  Property
  cathetan

  DETERMINISTIK = BENER
  Kudu diumumake kanthi eksplisit minangka atribut metode Microsoft .NET Framework.

  PRESISI = BENER
  Kudu diumumake kanthi eksplisit minangka atribut metode .NET Framework.

  AKSES DATA = NO SQL
  Ditemtokake kanthi nyetel atribut DataAccess menyang DataAccessKind.None lan atribut SystemDataAccess menyang SystemDataAccessKind.None.

  AKSES EKSTERNAL = NO
  Properti iki standar kanggo NO kanggo rutinitas CLR.

• Tampilan kudu digawe kanthi nggunakake WITH SCHEMABINDING pilihan.
• Tampilan mung kudu ngrujuk tabel dhasar sing ana ing basis data sing padha karo tampilan. Tampilan ora bisa ngrujuk tampilan liyane.
• Pernyataan SELECT ing definisi tampilan kudu ora ngemot unsur Transact-SQL ing ngisor iki:

  COUNT
  Fungsi ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, LAN OPENXML)
  OUTER melu (LEFT, RIGHT, utawa FULL)

  Tabel asale (ditetepake kanthi nemtokake a SELECT pratelan ing FROM klausa)
  Gabung dhewe
  Nemtokake kolom kanthi nggunakake SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARP, utawa AVG
  Ekspresi tabel umum (CTE)

  ngawang1, teks, ntext, gambar, XML, utawa filestream kolom
  Subkueri
  OVER klausa, sing kalebu fungsi jendhela peringkat utawa agregat

  Predikat teks lengkap (CONTAINS, FREETEXT)
  SUM fungsi sing referensi ekspresi nullable
  ORDER BY

  Fungsi agregat sing ditemtokake pangguna CLR
  TOP
CUBE, ROLLUP, utawa GROUPING SETS operator

  MIN, MAX
UNION, EXCEPT, utawa INTERSECT operator
  TABLESAMPLE

  Tabel variabel
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  Set kolom jarang
  Inline (TVF) utawa multi-statement table-valued functions (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 Tampilan sing diindeks bisa ngemot ngawang kolom; Nanging, kolom kuwi ora bisa kalebu ing tombol indeks clustered.

• If GROUP BY saiki, definisi VIEW kudu ngemot COUNT_BIG(*) lan kudu ora ngemot HAVING. iki GROUP BY watesan mung ditrapake kanggo definisi tampilan sing diindeks. Pitakonan bisa nggunakake tampilan sing diindeks ing rencana eksekusi sanajan ora marem GROUP BY larangan.
• Yen andharan tampilan ngemot a GROUP BY klausa, tombol indeks clustered unik bisa ngrujuk mung kolom kasebut ing GROUP BY klausa.

Cetha ing kene yen wong India ora melu, amarga dheweke mutusake kanggo nindakake miturut skema "kita bakal nindakake sethithik, nanging kanthi becik." Tegese, dheweke duwe luwih akeh tambang ing lapangan, nanging lokasine luwih transparan. Sing paling nguciwani yaiku watesan iki:

Tampilan mung kudu ngrujuk tabel dhasar sing ana ing basis data sing padha karo tampilan. Tampilan ora bisa ngrujuk tampilan liyane.

Ing terminologi kita, iki tegese fungsi ora bisa ngakses fungsi materialized liyane. Iki ngethok kabeh ideologi ing pucuk.
Uga, watesan iki (lan luwih akeh ing teks) nyuda kasus panggunaan:

Pernyataan SELECT ing definisi tampilan kudu ora ngemot unsur Transact-SQL ing ngisor iki:

COUNT
Fungsi ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, LAN OPENXML)
OUTER melu (LEFT, RIGHT, utawa FULL)

Tabel asale (ditetepake kanthi nemtokake a SELECT pratelan ing FROM klausa)
Gabung dhewe
Nemtokake kolom kanthi nggunakake SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, utawa AVG
Ekspresi tabel umum (CTE)

ngawang1, teks, ntext, gambar, XML, utawa filestream kolom
Subkueri
OVER klausa, sing kalebu fungsi jendhela peringkat utawa agregat

Predikat teks lengkap (CONTAINS, FREETEXT)
SUM fungsi sing referensi ekspresi nullable
ORDER BY

Fungsi agregat sing ditemtokake pangguna CLR
TOP
CUBE, ROLLUP, utawa GROUPING SETS operator

MIN, MAX
UNION, EXCEPT, utawa INTERSECT operator
TABLESAMPLE

Tabel variabel
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Set kolom jarang
Inline (TVF) utawa multi-statement table-valued functions (MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOIN, UNION, ORDER BY lan liya-liyane dilarang. Bisa uga luwih gampang kanggo nemtokake apa sing bisa digunakake tinimbang apa sing ora bisa digunakake. Daftar kasebut bisa uga luwih cendhek.

Kanggo ngringkes: set ageng watesan ing saben (ayo dicathet komersial) DBMS vs ora ana (kajaba siji logis, ora teknis) ing teknologi LGPL. Nanging, kudu dicathet yen ngleksanakake mekanisme iki ing logika relasional luwih angel tinimbang ing logika fungsional sing diterangake.

Реализация

Cara kerjane? PostgreSQL digunakake minangka "mesin virtual". Ana algoritma rumit ing njero sing nggawe pitakon. kene sumber. Lan ana ora mung pesawat gedhe saka heuristik karo Bunch saka ifs. Dadi, yen sampeyan duwe sawetara wulan sinau, sampeyan bisa nyoba ngerti arsitektur.

Apa bisa efektif? Cukup efektif. Sayange, iki angel dibuktekake. Aku mung bisa ngomong yen sampeyan nganggep ewonan pitakon sing ana ing aplikasi gedhe, mula rata-rata luwih efisien tinimbang pangembang sing apik. Programmer SQL sing apik banget bisa nulis pitakon kanthi luwih efisien, nanging kanthi sewu pitakon, dheweke ora duwe motivasi utawa wektu kanggo nindakake. Siji-sijine sing saiki bisa dakkandhakake minangka bukti efektifitas yaiku sawetara proyek nggarap platform sing dibangun ing DBMS iki. sistem ERP, sing duwe ewu fungsi MATERIALIZED beda, karo ewu pangguna lan database terabyte karo atusan yuta cathetan sing mlaku ing server loro-prosesor biasa. Nanging, sapa wae bisa mriksa / mbantah efektifitas kanthi ngundhuh platform lan PostgreSQL, nguripake logging query SQL lan nyoba kanggo ngganti logika lan data ana.

Ing artikel ing ngisor iki, aku uga bakal ngomong babagan carane sampeyan bisa nyetel watesan ing fungsi, nggarap sesi pangowahan, lan liya-liyane.

Source: www.habr.com