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

У претходном Чланак Описао сам концепт и имплементацију базе података изграђене на основу функција, а не на табелама и пољима као у релационим базама података. Дало је много примера који показују предности овог приступа у односу на класични. Многи су сматрали да нису довољно убедљиви.

У овом чланку ћу показати како вам овај концепт омогућава брзо и практично балансирање уписивања и читања у базу података без икаквих промена у оперативној логици. Слична функционалност је покушана да се имплементира у модерне комерцијалне ДБМС (посебно, Орацле и Мицрософт СКЛ Сервер). На крају чланка ћу показати да оно што су урадили, најблаже речено, није испало баш најбоље.

Опис

Као и раније, ради бољег разумевања почећу опис примерима. Рецимо да треба да имплементирамо логику која ће вратити списак одељења са бројем запослених у њима и њиховом укупном платом.

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

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


Сложеност извршавања овог упита у било ком ДБМС-у биће еквивалентна О (број запослених)јер овај прорачун захтева скенирање целе табеле запослених и затим њихово груписање по одељењима. Биће и неки мали (верујемо да је много више запослених него одељења) додатак у зависности од изабраног плана О (дневни број запослених) или О (број одељења) за груписање и тако даље.

Јасно је да трошкови извршења могу бити различити у различитим ДБМС-овима, али се сложеност неће променити ни на који начин.

У предложеној имплементацији, функционални ДБМС ће генерисати један потупит који ће израчунати потребне вредности за одељење, а затим направити ЈОИН са табелом одељења да би добио име. Међутим, за сваку функцију, приликом декларисања, могуће је поставити посебан маркер МАТЕРИАЛИЗЕД. Систем ће аутоматски креирати одговарајуће поље за сваку такву функцију. Када промените вредност функције, вредност поља ће се такође променити у истој трансакцији. Када приступите овој функцији, приступиће се унапред израчунатом пољу.

Конкретно, ако поставите МАТЕРИАЛИЗЕД за функције цоунтЕмплоиеес и салариСум, тада ће у табелу са листом одељења бити додата два поља у којима ће се чувати број запослених и њихова укупна зарада. Кад год дође до промене запослених, њихових плата или припадности одељењима, систем ће аутоматски променити вредности ових поља. Горњи упит ће директно приступити овим пољима и биће извршен у њима О (број одељења).

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

Пример:

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


Сам систем ће креирати једну табелу са типским кључевима Купац, производ и ИНТЕГЕР, ће му додати два поља и ажурирати вредности поља у њима свим променама. Када се изврше даљи позиви ових функција, оне неће бити израчунате, већ ће се вредности читати из одговарајућих поља.

Користећи овај механизам, можете, на пример, да се решите рекурзија (ЦТЕ) у упитима. Конкретно, размотрите групе које формирају стабло користећи однос дете/родитељ (свака група има везу са својим родитељем):

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


У СКЛ упиту неће бити ЦТЕ. Уместо тога, постојаће једноставна ГРОУП БИ.

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

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

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


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

Предности

Чему служи цео овај механизам? У класичним ДБМС-овима, без поновног писања упита, програмер или ДБА могу само да мењају индексе, одређују статистику и говоре планеру упита како да их изврши (а ХИНТ-ови су доступни само у комерцијалним ДБМС-овима). Колико год се трудили, неће моћи да допуне први упит у чланку у О (број одељења) без промене упита или додавања покретача. У предложеној шеми, у фази развоја не морате да размишљате о структури складиштења података и о томе које агрегације ћете користити. Све ово се може лако променити у ходу, директно у раду.

У пракси то изгледа овако. Неки људи развијају логику директно на основу задатка. Не разумеју алгоритме и њихову сложеност, ни планове извршења, ни типове спојева, нити било коју другу техничку компоненту. Ови људи су више пословни аналитичари него програмери. Затим, све ово иде у тестирање или рад. Омогућава евидентирање дуготрајних упита. Када се открије дугачак упит, онда други људи (више технички - у суштини ДБА) одлучују да омогуће МАТЕРИАЛИЗЕД на некој средњој функцији. Ово мало успорава снимање (пошто захтева ажурирање додатног поља у трансакцији). Међутим, није само овај упит значајно убрзан, већ и сви други који користе ову функцију. У исто време, релативно је лако одлучити која функција да се материјализује. Два главна параметра: број могућих улазних вредности (ово је колико записа ће бити у одговарајућој табели) и колико често се користи у другим функцијама.

Аналоги

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

Прво, можете да омогућите материјализацију само ако сте већ креирали обичан ПРЕГЛЕД. У супротном, мораћете да препишете преостале захтеве за приступ новокреираном приказу да бисте користили ову материјализацију. Или оставите све како јесте, али ће бити у најмању руку неефикасно ако постоје одређени већ унапред израчунати подаци, али многи упити их не користе увек, већ их поново израчунавају.

Друго, они имају велики број ограничења:

пророчанство

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) мора бити присутан. Орацле то препоручује SUM(expr) бити прецизиран.
• If VARIANCE(expr) or STDDEV(expr) је наведено, COUNT(expr) SUM(expr) мора бити наведен. Орацле то препоручује SUM(expr *expr) бити прецизиран.
• SELECT колона у упиту за дефинисање не може бити сложен израз са колонама из више основних табела. Могуће решење за ово је коришћење угнежђеног материјализованог погледа.
• SELECT листа мора да садржи све GROUP BY колоне.
• Материјализовани приказ није заснован на једној или више удаљених табела.
• Ако користите а CHAR тип података у колонама филтера дневника материјализованог приказа, скупови знакова главног сајта и материјализованог приказа морају бити исти.
• Ако материјализовани приказ има нешто од следећег, брзо освежавање је подржано само на конвенционалним ДМЛ уметцима и директним учитавањима.
  • Материјализовани погледи са MIN or MAX агрегати
  • Материјализовани погледи који имају SUM(expr) али не COUNT(expr)
  • Материјализовани погледи без COUNT(*)

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

• Материјализован поглед са MAX or MIN се брзо освежава након брисања или мешаних ДМЛ изјава ако нема а WHERE клаузула.
  Максимално/мин брзо освежавање након брисања или мешаног ДМЛ-а нема исто понашање као случај само за уметање. Брише и поново израчунава максималне/мин вредности за погођене групе. Морате бити свесни његовог утицаја на перформансе.
• Материјализовани прикази са именованим приказима или подупитима у FROM клаузула се може брзо освежити под условом да се погледи могу потпуно спојити. За информације о томе који ће се погледи спојити, погледајте Орацле Датабасе СКЛ Лангуаге Референце.
• Ако нема спољних спојева, можда ћете имати произвољне селекције и спојеве у WHERE клаузула.
• Материјализовани агрегатни прикази са спољним спојевима се брзо могу освежити након конвенционалног ДМЛ-а и директног учитавања, под условом да је само спољна табела измењена. Такође, морају постојати јединствена ограничења на колонама за спајање унутрашње табеле спајања. Ако постоје спољни спојеви, сви спојеви морају бити повезани помоћу ANDс и мора користити једнакост (=) оператер.
• За материјализоване погледе са CUBE, ROLLUP, груписање скупова или њихово спајање, примењују се следећа ограничења:
  • SELECT листа треба да садржи разликовач груписања који може бити а 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 подесити подршку оператера REFRESH FAST опцију ако су испуњени следећи услови:

• Упит за дефинисање мора да има UNION ALL оператер на највишем нивоу.

  UNION ALL оператор не може бити уграђен у потупит, са једним изузетком: Тхе UNION ALL може бити у потупиту у FROM клаузулу под условом да је упит за дефинисање облика SELECT * FROM (преглед или потупит са UNION ALL) као у следећем примеру:

  ЦРЕАТЕ ВИЕВ виев_витх_унионалл АС (ИЗАБИР ц.ровид црид, ц.цуст_ид, 2 умаркер ФРОМ купаца ц ВХЕРЕ ц.цуст_ласт_наме = 'Смитх' УНИОН АЛЛ СЕЛЕЦТ ц.ровид црид, ц.цуст_ид, 3 умаркер ФРОМ купаца ц ВХЕРЕ ц.цуст_ла 'Јонес'); НАПРАВИТЕ МАТЕРИЈАЛИЗОВАНИ ПРИКАЗ унионалл_инсиде_виев_мв БРЗО ОСВЕЖИТЕ НА ЗАХТЕВ КАО СЕЛЕЦТ * ФРОМ виев_витх_унионалл;
  

  Имајте на уму да поглед view_with_unionall задовољава захтеве за брзо освежавање.

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

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

• SELECT листа сваког упита мора да садржи а UNION ALL маркер, и UNION ALL колона мора имати различиту константну нумеричку или стринг вредност у свакој UNION ALL грана. Даље, колона маркера мора се појавити на истом редном месту у SELECT листа сваког блока упита. види "УНИОН АЛЛ Маркер и преписивање упита» за више информација о UNION ALL маркери.
• Неке функције као што су спољна спајања, збирни упити материјализованих приказа само за уметање и удаљене табеле нису подржане за материјализоване приказе са UNION ALL. Имајте на уму, међутим, да се материјализовани погледи који се користе у репликацији, а који не садрже спојеве или агрегате, могу брзо освежити када UNION ALL или се користе даљински столови.
• Параметар иницијализације компатибилности мора бити постављен на 9.2.0 или новији да би се креирао материјализовани приказ који се може брзо освежити са UNION ALL.

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

Мицрософт СКЛ Сервер

Додатни захтеви

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

• Корисник који извршава CREATE INDEX мора бити власник приказа.
• Када креирате индекс, IGNORE_DUP_KEY опција мора бити постављена на ОФФ (подразумевана поставка).
• Табеле морају бити референциране дводелним именима, шема.име табеле у дефиницији погледа.
• Кориснички дефинисане функције на које се упућује у приказу морају бити креиране коришћењем WITH SCHEMABINDING опција.
• Све кориснички дефинисане функције на које се упућује у приказу морају бити референциране дводелним именима, ..
• Својство приступа подацима кориснички дефинисане функције мора бити NO SQL, а својство спољног приступа мора бити NO.
• Функције Цоммон Лангуаге Рунтиме (ЦЛР) могу се појавити на листи избора приказа, али не могу бити део дефиниције кластеризованог индексног кључа. ЦЛР функције се не могу појавити у клаузули ВХЕРЕ у погледу или у клаузули ОН операције ЈОИН у погледу.
• ЦЛР функције и методе ЦЛР кориснички дефинисаних типова који се користе у дефиницији погледа морају имати својства постављена као што је приказано у следећој табели.

  Имовина
  белешке

  ДЕТЕРМИНИСТИЧНО = ТАЧНО
  Мора бити експлицитно декларисан као атрибут методе Мицрософт .НЕТ Фрамеворк.

  ПРЕЦИЗНО = ТАЧНО
  Мора бити експлицитно декларисан као атрибут методе .НЕТ Фрамеворк.

  ПРИСТУП ПОДАЦИМА = НЕМА СКЛ-а
  Одређује се подешавањем атрибута ДатаАццесс на ДатаАццессКинд.Ноне и СистемДатаАццесс атрибута на СистемДатаАццессКинд.Ноне.

  СПОЉНИ ПРИСТУП = НЕ
  Ово својство подразумевано је НЕ за ЦЛР рутине.

• Приказ мора бити креиран коришћењем WITH SCHEMABINDING опција.
• Поглед мора референцирати само основне табеле које се налазе у истој бази података као и поглед. Поглед не може референцирати друге погледе.
• Наредба СЕЛЕЦТ у дефиницији приказа не сме да садржи следеће Трансацт-СКЛ елементе:

  COUNT
  РОВСЕТ функције (OPENDATASOURCE, OPENQUERY, OPENROWSET, И OPENXML)
  OUTER придружује (LEFT, RIGHT, Или FULL)

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

  DISTINCT
STDEV, STDEVP, VAR, VARP, Или AVG
  Заједнички табеларни израз (ЦТЕ)

  пловак1, текст, нтект, слика, КСМЛ, Или филестреам колоне
  подупит
  OVER клаузулу, која укључује функције рангирања или агрегата прозора

  Предикати целог текста (CONTAINS, FREETEXT)
  SUM функција која упућује на израз који може бити нултан
  ORDER BY

  ЦЛР кориснички дефинисана агрегатна функција
  TOP
CUBE, ROLLUP, Или GROUPING SETS Оператори

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

  Табеларне варијабле
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  Ретки скупови колона
  Уграђене (ТВФ) или функције са табелом са више исказа (МСТВФ)
  OFFSET

  CHECKSUM_AGG

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

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

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

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

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

Наредба СЕЛЕЦТ у дефиницији приказа не сме да садржи следеће Трансацт-СКЛ елементе:

COUNT
РОВСЕТ функције (OPENDATASOURCE, OPENQUERY, OPENROWSET, И OPENXML)
OUTER придружује (LEFT, RIGHT, Или FULL)

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

DISTINCT
STDEV, STDEVP, VAR, VARP, Или AVG
Заједнички табеларни израз (ЦТЕ)

пловак1, текст, нтект, слика, КСМЛ, Или филестреам колоне
подупит
OVER клаузулу, која укључује функције рангирања или агрегата прозора

Предикати целог текста (CONTAINS, FREETEXT)
SUM функција која упућује на израз који може бити нултан
ORDER BY

ЦЛР кориснички дефинисана агрегатна функција
TOP
CUBE, ROLLUP, Или GROUPING SETS Оператори

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

Табеларне варијабле
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Ретки скупови колона
Уграђене (ТВФ) или функције са табелом са више исказа (МСТВФ)
OFFSET

CHECKSUM_AGG

СПОЉАШЊЕ СПОЈЕЊЕ, УНИОН, ОРДЕР БИ и друго су забрањени. Можда је било лакше одредити шта се може користити, а не шта се не може користити. Листа би вероватно била много краћа.

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

Имплементација

Како то ради? ПостгреСКЛ се користи као „виртуелна машина“. Унутра је сложен алгоритам који прави упите. Ево извор. И не постоји само велики скуп хеуристика са гомилом ако. Дакле, ако имате неколико месеци за учење, можете покушати да разумете архитектуру.

Да ли делује ефикасно? Прилично ефикасно. Нажалост, ово је тешко доказати. Могу само да кажем да ако узмете у обзир хиљаде упита који постоје у великим апликацијама, онда су они у просеку ефикаснији од оних код доброг програмера. Одличан СКЛ програмер може ефикасније да напише било који упит, али са хиљаду упита једноставно неће имати ни мотивације ни времена да то уради. Једино што сада могу да наведем као доказ ефикасности је да неколико пројеката ради на платформи изграђеној на овом ДБМС-у ЕРП системи, који имају хиљаде различитих МАТЕРИЈАЛИЗОВАНИХ функција, са хиљадама корисника и базама података терабајта са стотинама милиона записа који раде на редовном серверу са два процесора. Међутим, свако може да провери/побије ефикасност преузимањем платформа и ПостгреСКЛ, укључен евидентирање СКЛ упита и покушај промене логике и података тамо.

У следећим чланцима ћу такође говорити о томе како можете да поставите ограничења функцијама, радите са сесијама промена и још много тога.

Извор: ввв.хабр.цом