Балансирање пишува и чита во база на податоци

Во претходниот Член Го опишав концептот и имплементацијата на базата на податоци изградена врз основа на функции, наместо табели и полиња како во релационите бази на податоци. Даде многу примери кои ги покажуваат предностите на овој пристап во однос на класичниот. Многумина ги сметаа за недоволно убедливи.

Во оваа статија, ќе покажам како овој концепт ви овозможува брзо и практично да ги балансирате пишувањата и читањата во базата на податоци без никаква промена во оперативната логика. Слична функционалност се обиде да се имплементира во современите комерцијални DBMS (особено Oracle и Microsoft SQL Server). На крајот од статијата ќе покажам дека она што тие го направија, благо кажано, не успеа многу добро.

Опис

Како и досега, за подобро разбирање ќе го започнам описот со примери. Да речеме дека треба да спроведеме логика која ќе врати список на одделенија со бројот на вработени во нив и нивната вкупна плата.

Во функционална база на податоци, тоа би изгледало вака:

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


Комплексноста на извршувањето на ова барање во која било DBMS ќе биде еквивалентна на О (број на вработени)бидејќи оваа пресметка бара скенирање на целата табела на вработени и потоа нивно групирање по оддел. Ќе има и мал додаток (веруваме дека има многу повеќе вработени отколку одделенија) во зависност од избраниот план O (дневник на бројот на вработени) или O (број на одделенија) за групирање и сл.

Јасно е дека трошоците за извршување може да бидат различни во различни DBMS, но сложеноста нема да се промени на кој било начин.

Во предложената имплементација, функционалниот DBMS ќе генерира едно подпрашање кое ќе ги пресмета потребните вредности за одделот, а потоа ќе направи JOIN со табелата на одделот за да го добие името. Меѓутоа, за секоја функција, при декларирање, можно е да се постави посебен МАТЕРИЈАЛИЗИРАН маркер. Системот автоматски ќе создаде соодветно поле за секоја таква функција. При промена на вредноста на функцијата, вредноста на полето исто така ќе се промени во истата трансакција. При пристап до оваа функција, ќе се пристапи до претходно пресметаното поле.

Особено, ако поставите MATERIALIZED за функции броиВработени и плата Збир, потоа во табелата со списокот одделенија ќе се додадат две полиња во кои ќе се зачува бројот на вработени и нивната вкупна плата. Секогаш кога ќе дојде до промена на вработените, нивните плати или припадности на одделот, системот автоматски ќе ги менува вредностите на овие полиња. Горенаведеното барање директно ќе пристапи до овие полиња и ќе се изврши во O (број на одделенија).

Кои се ограничувањата? Само една работа: таквата функција мора да има конечен број на влезни вредности за кои е дефинирана нејзината вредност. Во спротивно, ќе биде невозможно да се изгради табела што ги складира сите нејзини вредности, бидејќи не може да има табела со бесконечен број редови.

Пример:

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


Оваа функција е дефинирана за бесконечен број вредности од N (на пример, секоја негативна вредност е погодна). Затоа, на него не можете да ставите МАТЕРИЈАЛИЗИРАНО. Значи, ова е логично ограничување, а не техничко (односно, не затоа што не можевме да го спроведеме). Во спротивно, нема ограничувања. Можете да користите групирања, сортирање, И и ИЛИ, ПОДЕЛБА, рекурзија итн.

На пример, во проблемот 2.2 од претходната статија, можете да ставите МАТЕРИЈАЛИЗИРАНО на двете функции:

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;


Самиот систем ќе создаде една табела со копчиња за тип Клиент, Производ и ЦЕЛ БРОЈ, ќе додаде две полиња на него и ќе ги ажурира вредностите на полињата во нив со какви било промени. Кога ќе се направат дополнителни повици до овие функции, тие нема да се пресметуваат, туку вредностите ќе се читаат од соодветните полиња.

Користејќи го овој механизам, можете, на пример, да се ослободите од рекурзии (CTE) во барањата. Посебно, разгледајте ги групите кои формираат дрво користејќи го односот дете/родител (секоја група има врска до својот родител):

parent = DATA Group (Group);


Во функционална база на податоци, логиката на рекурзија може да се наведе на следниов начин:

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;


Бидејќи за функцијата е Родител се означува МАТЕРИЈАЛИЗИРАНО, потоа за неа ќе се креира табела со два клуча (групи) во која полето е Родител ќе биде точно само ако првиот клуч е дете на вториот. Бројот на записи во оваа табела ќе биде еднаков на бројот на групи помножен со просечната длабочина на дрвото. Ако ви треба, на пример, да го броите бројот на потомци на одредена група, можете да ја користите оваа функција:

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


Нема да има CTE во барањето SQL. Наместо тоа ќе има едноставна GROUP BY.

Користејќи го овој механизам, можете лесно да ја денормализирате базата на податоци доколку е потребно:

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

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


Кога повикувате функција датум за редот за нарачки, полето за кое има индекс ќе се чита од табелата со линии за нарачки. Кога ќе се промени датумот на нарачката, самиот систем автоматски повторно ќе го пресмета денормализираниот датум во линијата.

Предности

За што служи целиот овој механизам? Во класичните DBMS, без препишување прашања, развивачот или DBA може само да менува индекси, да одредува статистика и да му каже на планерот за прашања како да ги изврши (а HINTs се достапни само во комерцијалните DBMS). Колку и да се трудат, нема да можат да го завршат првото барање во написот во O (број на одделенија) без промена на прашања или додавање предизвикувачи. Во предложената шема, во фазата на развој не треба да размислувате за структурата за складирање податоци и кои агрегации да ги користите. Сето ова може лесно да се смени во лет, директно при работа.

Во пракса тоа изгледа вака. Некои луѓе развиваат логика директно заснована на задачата што ја имаат. Тие не ги разбираат алгоритмите и нивната сложеност, плановите за извршување, видовите спојувања или која било друга техничка компонента. Овие луѓе се повеќе деловни аналитичари отколку програмери. Потоа, сето ова оди во тестирање или работа. Овозможува евидентирање на долготрајни прашања. Кога ќе се открие долго барање, тогаш други луѓе (потехнички - во суштина DBA) одлучуваат да овозможат МАТЕРИЈАЛИЗИРАНО на некоја средна функција. Ова малку го успорува снимањето (бидејќи бара ажурирање на дополнително поле во трансакцијата). Сепак, не само ова барање е значително забрзано, туку и сите други што ја користат оваа функција. Во исто време, одлучувањето која функција да се материјализира е релативно лесно. Два главни параметри: бројот на можни влезни вредности (ова е колку записи ќе има во соодветната табела) и колку често се користи во други функции.

Аналози

Современите комерцијални DBMS имаат слични механизми: МАТЕРИЈАЛИЗИРАН ПОГЛЕД со БРЗО ОСВЕЖУВАЊЕ (Oracle) и ИНДЕКСИРАН ПОГЛЕД (Microsoft SQL Server). Во PostgreSQL, MATERIALIZED VIEW не може да се ажурира во трансакција, туку само на барање (па дури и со многу строги ограничувања), па затоа не го разгледуваме. Но, тие имаат неколку проблеми кои значително ја ограничуваат нивната употреба.

Прво, можете да овозможите материјализација само ако веќе сте создале редовен VIEW. Во спротивно, ќе мора да ги преработите преостанатите барања за пристап до новосоздадениот приказ за да ја користите оваа материјализација. Или оставете сè како што е, но тоа ќе биде барем неефикасно ако има одредени веќе претходно пресметани податоци, но многу прашања не секогаш ги користат, туку повторно ги пресметуваат.

Второ, тие имаат огромен број ограничувања:

Oracle

5.3.8.4 Општи ограничувања за брзо освежување

Дефинитивното барање на материјализираниот поглед е ограничено на следниов начин:

• Материјализираниот приказ не смее да содржи референци за изрази што не се повторуваат како SYSDATE ROWNUM.
• Материјализираниот поглед не смее да содржи референци за RAW or LONG RAW типови на податоци.
• Не може да содржи а SELECT листа подпрашање.
• Не може да содржи аналитички функции (на пример, RANK) во SELECT клаузула.
• Не може да упатува на табела на која XMLIndex се дефинира индекс.
• Не може да содржи а MODEL клаузула.
• Не може да содржи а HAVING клаузула со подпрашање.
• Не може да содржи вгнездени прашања што имаат ANY, ALLили NOT EXISTS.
• Не може да содржи а [START WITH …] CONNECT BY клаузула.
• Не може да содржи повеќе табели со детали на различни локации.
• ON COMMIT материјализираните погледи не можат да имаат табели со далечински детали.
• Вгнездените материјализирани погледи мора да имаат спој или агрегат.
• Материјализирани здружени ставови и материјализирани збирни погледи со а GROUP BY клаузулата не може да избере од табела организирана со индекс.

5.3.8.5 Ограничувања за брзо освежување на материјализирани погледи само со спојувања

Дефинирањето на барања за материјализирани прикази само со спојувања и без агрегати ги има следните ограничувања за брзо освежување:

• Сите ограничувања од «Општи ограничувања за брзо освежување".
• Тие не можат да имаат GROUP BY клаузули или агрегати.
• Редови од сите табели во FROM списокот мора да се појави во SELECT список на барањето.
• Материјализираните дневници за приказ мора да постојат со редови за сите основни табели во FROM список на барањето.
• Не можете да креирате материјализиран приказ со брзо освежување од повеќе табели со едноставни спојувања кои вклучуваат колона од тип на објект во SELECT изјава.

Исто така, методот на освежување што ќе го изберете нема да биде оптимално ефикасен ако:

• Дефинитивното барање користи надворешен спој кој се однесува како внатрешен спој. Ако дефинирачкото барање содржи такво спојување, размислете да го препишете дефинирачкото барање за да содржи внатрешен спој.
• на SELECT списокот на материјализираниот приказ содржи изрази на колони од повеќе табели.

5.3.8.6 Ограничувања за брзо освежување на материјализирани погледи со агрегати

Дефинирањето на барања за материјализирани прикази со агрегати или спојувања ги имаат следните ограничувања за брзо освежување:

• Сите ограничувања од «Општи ограничувања за брзо освежување".

Брзо освежување е поддржано и за двете ON COMMIT ON DEMAND материјализирани ставови, но се применуваат следните ограничувања:

• Сите табели во материјализираниот приказ мора да имаат материјализирани дневници за приказ, а материјализираните дневници за приказ мора:
  • Ги содржи сите колони од табелата наведени во материјализираниот приказ.
  • Наведете со ROWID INCLUDING NEW VALUES.
  • Одредете го SEQUENCE клаузула ако се очекува табелата да има мешавина од вметнувања/директни вчитувања, бришења и ажурирања.

• Само SUM, COUNT, AVG, STDDEV, VARIANCE, MIN MAX се поддржани за брзо освежување.
• COUNT(*) мора да се наведе.
• Агрегатните функции мора да се појавуваат само како најоддалечен дел од изразот. Односно, агрегати како што се AVG(AVG(x)) or AVG(x)+ AVG(x) не се дозволени.
• За секој агрегат како на пр AVG(expr), соодветните COUNT(expr) мора да бидат присутни. Oracle го препорачува тоа SUM(expr) да бидат наведени.
• If VARIANCE(expr) or STDDEV(expr) е наведено, COUNT(expr) SUM(expr) мора да се наведе. Oracle го препорачува тоа SUM(expr *expr) да бидат наведени.
• на SELECT колоната во дефинирачкото барање не може да биде сложен израз со колони од повеќе базни табели. Можно решение за ова е да се користи вгнезден материјализиран поглед.
• на SELECT списокот мора да ги содржи сите GROUP BY колони.
• Материјализираниот приказ не се заснова на една или повеќе оддалечени табели.
• Ако користите CHAR типот на податоци во колоните за филтрирање на дневникот за материјализиран преглед, множествата на знаци на главниот сајт и материјализираниот приказ мора да бидат исти.
• Ако материјализираниот приказ има едно од следниве, тогаш брзото освежување е поддржано само на конвенционалните DML инсерти и директни вчитувања.
  • Материјализирани ставови со MIN or MAX агрегати
  • Материјализирани ставови кои имаат SUM(expr) но не COUNT(expr)
  • Материјализирани ставови без COUNT(*)

  Ваквиот материјализиран поглед се нарекува материјализиран поглед само за вметнување.

• Материјализиран поглед со MAX or MIN брзо се освежува по бришење или измешани DML изјави ако нема a WHERE клаузула.
  Максималното/минутно брзо освежување по бришење или измешано DML го нема истото однесување како случајот само за вметнување. Ги брише и пресметува максималните/мин. вредности за погодените групи. Треба да бидете свесни за неговото влијание врз перформансите.
• Материјализирани погледи со именувани ставови или подпрашања во FROM клаузулата може брзо да се освежи под услов погледите целосно да се спојат. За информации за тоа кои погледи ќе се спојат, видете Референца за јазик на Oracle Database SQL.
• Ако нема надворешни спојувања, може да имате произволни селекции и спојувања во WHERE клаузула.
• Материјализираните збирни прикази со надворешни спојници брзо се освежуваат по конвенционалните DML и директни оптоварувања, под услов само надворешната табела да е изменета. Исто така, мора да постојат уникатни ограничувања на спојните колони на табелата за внатрешно спојување. Ако има надворешни спојки, сите спојки мора да бидат поврзани со ANDи мора да ја користи еднаквоста (=) оператор.
• За материјализирани ставови со CUBE, ROLLUP, групирање множества или нивно спојување, се применуваат следниве ограничувања:
  • на SELECT списокот треба да содржи разграничување за групирање што може да биде или a GROUPING_ID функционираат на сите GROUP BY изрази или GROUPING функции по една за секој GROUP BY изразување. На пример, ако на GROUP BY клаузула од материјализираниот став е „GROUP BY CUBE(a, b)“, потоа на SELECT списокот треба да содржи или „GROUPING_ID(a, b)» или «GROUPING(a) AND GROUPING(b)» за материјализираниот поглед брзо да се освежува.
  • GROUP BY не треба да резултира со дупликат групирања. На пример, "GROUP BY a, ROLLUP(a, b)„Не се освежува брзо бидејќи резултира со дупликат групирања“(a), (a, b), AND (a)".

5.3.8.7 Ограничувања за брзо освежување на материјализирани погледи со UNION ALL

Материјализирани ставови со UNION ALL во собата оператор поддршка на REFRESH FAST опција доколку се исполнети следните услови:

• Дефинитивното барање мора да го има UNION ALL оператор на највисоко ниво.

  на UNION ALL операторот не може да биде вграден во подпрашање, со еден исклучок: The UNION ALL може да биде во подпрашање во FROM клаузула под услов дефинирачкото барање да биде во форма SELECT * FROM (преглед или подпрашање со UNION ALL) како во следниот пример:

  КРЕИРАЈ ПОГЛЕД view_with_unionall AS
  (ИЗБЕРЕТЕ c.rowid crid, c.cust_id, 2 umarker
   ОД клиенти в КАДЕ c.cust_last_name = 'Смит'
   УНИЈА СИТЕ
   SELECT c.rowid crid, c.cust_id, 3 umarker
   ОД клиенти в КАДЕ c.cust_last_name = 'Џонс');
  
  СОЗДАДЕТЕ МАТЕРИЈАЛИЗИРАН ПОГЛЕД unionall_inside_view_mv
  ОСВЕЖУВАЈ БРЗО НА БАРАЊЕ КАКО
  ИЗБЕРИ * ОД поглед_со_унион-сите;
  

  Забележете дека погледот view_with_unionall ги задоволува барањата за брзо освежување.

• Секој блок за пребарување во UNION ALL барањето мора да ги задоволи барањата за брзо освежувачки материјализиран приказ со агрегати или брзо освежувачки материјализиран приказ со спојници.

  Соодветните материјализирани дневници за преглед мора да се креираат на табелите како што се бара за соодветниот тип на материјализиран приказ со брзо освежување.
  Имајте на ум дека Oracle базата на податоци, исто така, дозволува посебен случај на една табела материјализиран поглед со спојувања само под услов ROWID колоната е вклучена во SELECT список и во дневникот за материјализиран поглед. Ова е прикажано во дефинирачкото барање на приказот view_with_unionall.

• на SELECT списокот на секое барање мора да содржи a UNION ALL маркер, и UNION ALL колоната мора да има посебна константна нумеричка или стрингна вредност во секоја од нив UNION ALL гранка. Понатаму, колоната за маркер мора да се појави во истата редовна положба во SELECT листа на секој блок за прашања. Види "UNION ALL Обележувач и препишување на барањето» за повеќе информации во врска со UNION ALL маркери.
• Некои функции како што се надворешни спојувања, барања за збирен материјализиран преглед само за вметнување и оддалечени табели не се поддржани за материјализирани прикази со UNION ALL. Забележете, сепак, дека материјализираните прикази што се користат во репликацијата, кои не содржат спојувања или агрегати, може брзо да се освежат кога UNION ALL или се користат далечински табели.
• Параметарот за иницијализација на компатибилноста мора да се постави на 9.2.0 или повисоко за да се создаде брзо освежувачки материјализиран приказ со UNION ALL.

Не сакам да ги навредам обожавателите на Oracle, но судејќи според нивната листа на ограничувања, се чини дека овој механизам е напишан не во општиот случај, користејќи некој вид модел, туку од илјадници Индијци, каде на сите им беше дадена можност да напишете своја гранка и секој од нив направи што можеше и направи. Користењето на овој механизам за вистинска логика е како одење низ минско поле. Можете да добиете мина во секое време со притискање на едно од неочигледните ограничувања. Како функционира е исто така посебно прашање, но тоа е надвор од опсегот на овој напис.

Microsoft SQL Server,

Дополнителни барања

Покрај опциите SET и барањата за детерминистичка функција, мора да се исполнат и следниве барања:

• Корисникот што извршува CREATE INDEX мора да биде сопственик на погледот.
• Кога ќе го креирате индексот, на IGNORE_DUP_KEY опцијата мора да биде поставена на OFF (стандардна поставка).
• Табелите мора да бидат референцирани со имиња од два дела, Шемата.име на маса во дефиницијата за поглед.
• Функциите дефинирани од корисникот наведени во приказот мора да се креираат со користење на WITH SCHEMABINDING опција.
• Сите функции дефинирани од корисникот наведени во приказот мора да бидат референцирани со имиња од два дела, ..
• Својството за пристап до податоци на функцијата дефинирана од корисникот мора да биде NO SQL, а имотот за надворешен пристап мора да биде NO.
• Функциите за извршување на обичниот јазик (CLR) може да се појават во списокот за избор на приказот, но не можат да бидат дел од дефиницијата на кластерираниот индексен клуч. Функциите CLR не можат да се појават во клаузулата WHERE на приказот или клаузулата ON на операцијата JOIN во приказот.
• CLR функциите и методите на типовите дефинирани од корисникот CLR што се користат во дефиницијата за преглед мора да ги имаат поставените својства како што е прикажано во следната табела.

  Сопственост
  забелешка

  ДЕТЕРМИНИСТИЧКО = ВИСТИНСКИ
  Мора да се декларира експлицитно како атрибут на методот Microsoft .NET Framework.

  ПРЕЦИЗНО = ВИСТИНСКИ
  Мора да се декларира експлицитно како атрибут на методот .NET Framework.

  ПРИСТАП НА ПОДАТОЦИ = НЕМА SQL
  Утврдено со поставување на атрибутот DataAccess на DataAccessKind.None и SystemDataAccess на SystemDataAccessKind.None.

  НАДВОРЕШЕН ПРИСТАП = БР
  Ова својство е стандардно NO за CLR рутините.

• Погледот мора да се креира со користење на WITH SCHEMABINDING опција.
• Погледот мора да упатува само на базни табели кои се во истата база на податоци како и приказот. Погледот не може да упатува на други погледи.
• Изјавата SELECT во дефиницијата за преглед не смее да ги содржи следните елементи на Transact-SQL:

  COUNT
  Функции ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, И OPENXML)
  OUTER се приклучува (LEFT, RIGHTили FULL)

  Изведена табела (дефинирана со наведување a SELECT изјава во FROM клаузула)
  Само-приклучување
  Одредување колони со користење SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARPили AVG
  Заеднички израз на табелата (CTE)

  плови1, текст, ntext, слика, XMLили проток на датотеки колумни
  subquery
  OVER клаузула, која вклучува рангирање или збирни функции на прозорецот

  Предикати со целосен текст (CONTAINS, FREETEXT)
  SUM функција која упатува на поништен израз
  ORDER BY

  CLR збирна функција дефинирана од корисникот
  TOP
CUBE, ROLLUPили GROUPING SETS оператори

  MIN, MAX
UNION, EXCEPTили INTERSECT оператори
  TABLESAMPLE

  Променливи на табелата
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  Ретки множества колони
  Вградени (TVF) или функции вреднувани според табелата со повеќе изјави (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 Индексираниот приказ може да содржи плови колони; сепак, таквите колони не можат да бидат вклучени во кластерираниот индексен клуч.

• If GROUP BY е присутна, дефиницијата VIEW мора да содржи COUNT_BIG(*) и не смее да содржи HAVING. овие GROUP BY ограничувањата се применливи само за дефиницијата за индексиран приказ. Барањето може да користи индексиран приказ во својот план за извршување дури и ако не ги задоволува овие GROUP BY ограничувања.
• Ако дефиницијата за поглед содржи a GROUP BY клаузула, клучот на уникатниот кластериран индекс може да ги повикува само колоните наведени во GROUP BY клаузула.

Овде е јасно дека Индијците не беа вклучени, бидејќи тие решија да го направат тоа според шемата „ние ќе направиме малку, но добро“. Односно, имаат повеќе мини на теренот, но нивната локација е потранспарентна. Најразочарувачки е ова ограничување:

Погледот мора да упатува само на базни табели кои се во истата база на податоци како и приказот. Погледот не може да упатува на други погледи.

Во нашата терминологија, тоа значи дека функцијата не може да пристапи до друга материјализирана функција. Ова ја намалува целата идеологија во пупка.
Исто така, ова ограничување (и понатаму во текстот) во голема мера ги намалува случаите на употреба:

Изјавата SELECT во дефиницијата за преглед не смее да ги содржи следните елементи на Transact-SQL:

COUNT
Функции ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, И OPENXML)
OUTER се приклучува (LEFT, RIGHTили FULL)

Изведена табела (дефинирана со наведување a SELECT изјава во FROM клаузула)
Само-приклучување
Одредување колони со користење SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARPили AVG
Заеднички израз на табелата (CTE)

плови1, текст, ntext, слика, XMLили проток на датотеки колумни
subquery
OVER клаузула, која вклучува рангирање или збирни функции на прозорецот

Предикати со целосен текст (CONTAINS, FREETEXT)
SUM функција која упатува на поништен израз
ORDER BY

CLR збирна функција дефинирана од корисникот
TOP
CUBE, ROLLUPили GROUPING SETS оператори

MIN, MAX
UNION, EXCEPTили INTERSECT оператори
TABLESAMPLE

Променливи на табелата
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Ретки множества колони
Вградени (TVF) или функции вреднувани според табелата со повеќе изјави (MSTVF)
OFFSET

CHECKSUM_AGG

Забранети се НАДВОРЕШНИ ПРИКЛУЧУВАЊА, УНИЈА, НАРАЧКИ ПО и други. Можеби беше полесно да се одреди што може да се користи наместо што не може да се користи. Списокот веројатно би бил многу помал.

Да резимираме: огромен сет на ограничувања во секој (да забележиме комерцијален) DBMS наспроти ниеден (со исклучок на еден логичен, не технички) во технологијата LGPL. Сепак, треба да се забележи дека спроведувањето на овој механизам во релационата логика е нешто потешко отколку во опишаната функционална логика.

Реализация

Како работи? PostgreSQL се користи како „виртуелна машина“. Внатре има комплексен алгоритам кој гради прашања. Еве извор. И не постои само голем сет на хеуристики со еден куп ако е. Значи, ако имате неколку месеци за учење, можете да се обидете да ја разберете архитектурата.

Дали работи ефикасно? Доста ефикасно. За жал, тоа е тешко да се докаже. Можам само да кажам дека ако ги земете предвид илјадниците барања што постојат во големите апликации, тогаш во просек тие се поефикасни од оние на добар програмер. Одличен SQL програмер може да напише секое барање поефикасно, но со илјада прашања тој едноставно нема да има мотивација или време да го направи тоа. Единственото нешто што сега можам да го наведам како доказ за ефективноста е дека неколку проекти работат на платформата изградена на овој DBMS ERP системи, кои имаат илјадници различни МАТЕРИЈАЛИЗИРАНИ функции, со илјадници корисници и бази на податоци од терабајти со стотици милиони записи кои работат на обичен сервер со два процесори. Сепак, секој може да ја провери/побие ефективноста со преземање платформа и PostgreSQL, вклучено евидентирање на SQL прашања и обид за промена на логиката и податоците таму.

Во следните статии, ќе зборувам и за тоа како можете да поставите ограничувања на функциите, да работите со сесии за промени и многу повеќе.

Извор: www.habr.com