Балансиране на записи и четения в базата данни

В предишния Статия Описах концепцията и изпълнението на база данни, изградена на базата на функции, а не на таблици и полета, както е в релационните бази данни. Той даде много примери, показващи предимствата на този подход пред класическия. Мнозина ги намериха за недостатъчно убедителни.

В тази статия ще покажа как тази концепция ви позволява бързо и удобно да балансирате записи и четения в базата данни без промяна в операционната логика. Подобна функционалност се опитва да бъде внедрена в съвременни търговски СУБД (по-специално 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);


Сложността на изпълнението на тази заявка във всяка СУБД ще бъде еквивалентна на O(брой служители)защото това изчисление изисква сканиране на цялата таблица със служители и след това групирането им по отдели. Ще има и някои малки (ние вярваме, че има много повече служители, отколкото отдели) добавки в зависимост от избрания план O (регистриран брой служители) или O (брой отдели) за групиране и така нататък.

Ясно е, че разходите за изпълнение може да са различни в различните СУБД, но сложността няма да се промени по никакъв начин.

В предложената реализация функционалната СУБД ще генерира една подзаявка, която ще изчисли необходимите стойности за отдела и след това ще направи JOIN с таблицата на отдела, за да получи името. Въпреки това, за всяка функция при деклариране е възможно да се зададе специален маркер MATERIALIZED. Системата автоматично ще създаде съответното поле за всяка такава функция. Когато променяте стойността на функция, стойността на полето също ще се промени в същата транзакция. При достъп до тази функция ще бъде достъпно предварително изчисленото поле.

По-специално, ако зададете MATERIALIZED за функции countEmployees и заплатаSum, тогава към таблицата със списъка на отделите ще бъдат добавени две полета, които ще съхраняват броя на служителите и общата им заплата. Винаги, когато има промяна в служителите, техните заплати или принадлежност към отдел, системата автоматично ще промени стойностите на тези полета. Горната заявка ще има директен достъп до тези полета и ще бъде изпълнена в O (брой отдели).

Какви са ограниченията? Само едно нещо: такава функция трябва да има краен брой входни стойности, за които е дефинирана нейната стойност. В противен случай ще бъде невъзможно да се изгради таблица, която съхранява всичките си стойности, тъй като не може да има таблица с безкраен брой редове.

Пример:

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


Тази функция е дефинирана за безкраен брой стойности на N (например всяка отрицателна стойност е подходяща). Следователно не можете да поставите МАТЕРИАЛИЗИРАНО върху него. Така че това е логическо ограничение, а не техническо (тоест не защото не можахме да го приложим). Иначе няма ограничения. Можете да използвате групиране, сортиране, И и ИЛИ, PARTITION, рекурсия и т.н.

Например в проблем 2.2 от предишната статия можете да поставите MATERIALIZED и на двете функции:

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;


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

предимства

За какво е целият този механизъм? В класическите СУБД, без пренаписване на заявки, разработчикът или DBA могат само да променят индекси, да определят статистики и да казват на планиращия заявки как да ги изпълни (и HINT са налични само в комерсиални СУБД). Колкото и да се опитват, няма да могат да изпълнят първото запитване в статията в O (брой отдели) без промяна на заявки или добавяне на тригери. В предложената схема на етапа на разработка не е нужно да мислите за структурата за съхранение на данни и кои агрегати да използвате. Всичко това може лесно да се промени в движение, директно по време на работа.

На практика това изглежда така. Някои хора развиват логика директно въз основа на поставената задача. Те не разбират алгоритми и тяхната сложност, нито планове за изпълнение, нито видове съединения, нито какъвто и да е друг технически компонент. Тези хора са повече бизнес анализатори, отколкото разработчици. След това всичко това преминава в тестване или експлоатация. Позволява регистриране на дългосрочни заявки. Когато бъде открита дълга заявка, тогава други хора (по-технически - по същество DBA) решават да активират MATERIALIZED на някаква междинна функция. Това малко забавя записа (тъй като изисква актуализиране на допълнително поле в транзакцията). Но не само тази заявка се ускорява значително, но и всички други, които използват тази функция. В същото време решаването коя функция да се материализира е относително лесно. Два основни параметъра: броят на възможните входни стойности (това е колко записа ще има в съответната таблица) и колко често се използва в други функции.

аналози

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

Първо, можете да активирате материализация само ако вече сте създали обикновен VIEW. В противен случай ще трябва да пренапишете останалите заявки за достъп до новосъздадения изглед, за да използвате тази материализация. Или оставете всичко както е, но ще бъде поне неефективно, ако има определени вече предварително изчислени данни, но много заявки не винаги ги използват, но ги преизчисляват.

Второ, те имат огромен брой ограничения:

Оракул

5.3.8.4 Общи ограничения за бързо опресняване

Дефиниращата заявка на материализирания изглед е ограничена, както следва:

• Материализираният изглед не трябва да съдържа препратки към неповтарящи се изрази като SYSDATE намлява ROWNUM.
• Материализираният изглед не трябва да съдържа препратки към RAW or LONG RAW типове данни.
• Не може да съдържа a SELECT подзаявка за списък.
• Не може да съдържа аналитични функции (напр. RANK) В SELECT клауза.
• Не може да препраща към таблица, на която an XMLIndex индексът е определен.
• Не може да съдържа a MODEL клауза.
• Не може да съдържа a HAVING клауза с подзаявка.
• Не може да съдържа вложени заявки, които имат ANY, ALL или NOT EXISTS.
• Не може да съдържа a [START WITH …] CONNECT BY клауза.
• Не може да съдържа множество таблици с подробности на различни сайтове.
• ON COMMIT материализираните изгледи не могат да имат отдалечени таблици с подробности.
• Вложените материализирани изгледи трябва да имат съединение или агрегат.
• Материализирани съединителни изгледи и материализирани агрегатни изгледи с a 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 колони.
• Материализираният изглед не се основава на една или повече отдалечени таблици.
• Ако използвате a CHAR тип данни във филтърните колони на журнал на материализиран изглед, наборите от символи на главния сайт и материализирания изглед трябва да са еднакви.
• Ако материализираният изглед има едно от следните, тогава бързото опресняване се поддържа само при конвенционални DML вмъквания и директни зареждания.
  • Материализирани възгледи с MIN or MAX инертни материали
  • Материализирани възгледи, които имат SUM(expr) но не COUNT(expr)
  • Материализирани възгледи без COUNT(*)

  Такъв материализиран изглед се нарича материализиран изглед само за вмъкване.

• Материализиран изглед с MAX or MIN се опреснява бързо след изтриване или смесени DML изрази, ако няма a WHERE клауза.
  Макс./мин. бързо опресняване след изтриване или смесен DML няма същото поведение като случая само за вмъкване. Той изтрива и преизчислява макс./мин. стойности за засегнатите групи. Трябва да сте наясно с неговото въздействие върху ефективността.
• Материализирани изгледи с именувани изгледи или подзаявки в FROM клаузата може бързо да се опреснява, при условие че изгледите могат да бъдат напълно обединени. За информация кои изгледи ще се слеят, вижте Oracle Database SQL езиков справочник.
• Ако няма външни съединения, може да имате произволни селекции и съединения в WHERE клауза.
• Материализираните агрегатни изгледи с външни съединения могат бързо да се опресняват след конвенционален DML и директни зареждания, при условие че само външната таблица е била модифицирана. Освен това трябва да съществуват уникални ограничения върху колоните за свързване на вътрешната таблица за свързване. Ако има външни съединения, всички съединения трябва да бъдат свързани чрез ANDs и трябва да използва равенството (=) оператор.
• За материализирани възгледи с 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), както в следния пример:

  CREATE VIEW view_with_unionall AS (SELECT c.rowid crid, c.cust_id, 2 umarker FROM customers c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker FROM customers c WHERE c.cust_last_name = „Джоунс“); СЪЗДАВАНЕ НА МАТЕРИАЛИЗИРАН ИЗГЛЕД unionall_inside_view_mv ОБНОВЯВАНЕ БЪРЗО ПРИ ИСКАНЕ КАТО ИЗБЕРЕТЕ * ОТ view_with_unionall;
  

  Имайте предвид, че гледката 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.
• Функциите на Common Language Runtime (CLR) могат да се показват в списъка за избор на изгледа, но не могат да бъдат част от дефиницията на ключа на клъстерния индекс. CLR функциите не могат да се показват в клаузата WHERE на изгледа или клаузата ON на JOIN операция в изгледа.
• CLR функциите и методите на CLR потребителски дефинирани типове, използвани в дефиницията на изгледа, трябва да имат зададените свойства, както е показано в следващата таблица.

  Имот
  Забележка

  ДЕТЕРМИНИСТИЧНО = ВЯРНО
  Трябва да се декларира изрично като атрибут на метода на Microsoft .NET Framework.

  ТОЧНО = ИСТИНСКО
  Трябва да се декларира изрично като атрибут на метода на .NET Framework.

  ДОСТЪП ДАННИ = БЕЗ SQL
  Определя се чрез задаване на атрибута DataAccess на DataAccessKind.None и атрибута SystemDataAccess на SystemDataAccessKind.None.

  ВЪНШЕН ДОСТЪП = НЕ
  Това свойство по подразбиране е НЕ за 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 или файлов поток колони
  Подзаявка
  OVER клауза, която включва функции за класиране или сборен прозорец

  Пълнотекстови предикати (CONTAINS, FREETEXT)
  SUM функция, която препраща към nullable израз
  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 или файлов поток колони
Подзаявка
OVER клауза, която включва функции за класиране или сборен прозорец

Пълнотекстови предикати (CONTAINS, FREETEXT)
SUM функция, която препраща към nullable израз
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

OUTER JOINS, UNION, ORDER BY и други са забранени. Може би е било по-лесно да се посочи какво може да се използва, отколкото какво не може да се използва. Списъкът вероятно ще бъде много по-малък.

За да обобщим: огромен набор от ограничения във всяка (да отбележим комерсиална) СУБД срещу нито едно (с изключение на едно логическо, не техническо) в технологията LGPL. Все пак трябва да се отбележи, че прилагането на този механизъм в релационната логика е малко по-трудно, отколкото в описаната функционална логика.

Изпълнение

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

Работи ли ефективно? Доста ефективно. За съжаление това е трудно доказуемо. Мога само да кажа, че ако вземете предвид хилядите заявки, които съществуват в големи приложения, тогава средно те са по-ефективни от тези на добър разработчик. Един отличен SQL програмист може да напише всяка заявка по-ефективно, но с хиляди заявки той просто няма да има мотивация или време да го направи. Единственото нещо, което сега мога да цитирам като доказателство за ефективност е, че няколко проекта работят върху платформата, изградена върху тази СУБД ERP системи, които имат хиляди различни МАТЕРИАЛИЗИРАНИ функции, с хиляди потребители и терабайтови бази данни със стотици милиони записи, работещи на обикновен двупроцесорен сървър. Въпреки това, всеки може да провери/опровергае ефективността, като изтегли платформа и PostgreSQL, включен регистриране на SQL заявки и опит за промяна на логиката и данните там.

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

Източник: www.habr.com