Базадагы жазууну жана окууну балансташтыруу

Мурунку макала Мен реляциялык маалымат базаларындагыдай таблицалар жана талаалар эмес, функциялардын негизинде курулган маалымат базасынын түшүнүгүн жана ишке ашырылышын сүрөттөп бердим. Анда бул ыкманын классикалык ыкмага караганда артыкчылыктарын көрсөткөн көптөгөн мисалдар келтирилген. Көптөр аларды ынандырарлык эмес деп тапты.

Бул макалада мен бул концепциянын иштөө логикасында эч кандай өзгөрүүсүз маалымат базасына жазууларды жана окууларды тез жана ыңгайлуу теңдештирүүгө мүмкүндүк берерин көрсөтөм. Окшош функционалдуулук заманбап коммерциялык 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);


Бул суроону каалаган СББда аткаруунун татаалдыгы менен барабар болот О(кызматкерлердин саны)анткени бул эсептөө кызматкерлердин бүт таблицасын сканерлеп, анан бөлүм боюнча топтоштурууну талап кылат. Ошондой эле тандалган планга жараша чакан (бөлүмдөргө караганда кызматкерлер көп деп эсептейбиз) кошумчалар болот. O (кызматкерлердин журналы) же О (бөлүмдөрдүн саны) топтоого жана башкаларга.

Аткаруу кошумча чыгымдары ар кандай DBMSs ар кандай болушу мүмкүн экендиги түшүнүктүү, бирок татаалдыгы эч кандай өзгөрбөйт.

Сунуш кылынган ишке ашырууда функционалдык МБББ бөлүм үчүн керектүү маанилерди эсептеп, андан кийин аталышты алуу үчүн бөлүмдүн таблицасы менен КОШУУНУ түзө турган бир подсуроону жаратат. Бирок, ар бир функция үчүн, декларациялоодо, атайын МАТЕРИАЛДАЛГАН маркерди коюуга болот. Система автоматтык түрдө ар бир ушундай функция үчүн тиешелүү талааны түзөт. Функциянын маанисин өзгөртүүдө ошол эле транзакцияда талаанын мааниси да өзгөрөт. Бул функцияга киргенде, алдын ала эсептелген талаага кирүүгө болот.

Атап айтканда, сиз функциялар үчүн МАТЕРИАЛдаштырылган болсоңуз Кызматкерлердин саны и эмгек акы суммасы, андан кийин эки талаа бөлүмдөрдүн тизмеси менен таблицага кошулат, анда кызматкерлердин саны жана алардын жалпы эмгек акысы сакталат. Кызматкерлердин, алардын эмгек акысынын же бөлүмгө тиешелүүлүгүнүн өзгөрүүсү болгон сайын, система автоматтык түрдө бул талаалардын маанилерин өзгөртөт. Жогорудагы суроо бул талааларга түздөн-түз кире алат жана аткарылат О (бөлүмдөрдүн саны).

Кандай чектөөлөр бар? Бир гана нерсе: мындай функцияда анын мааниси аныкталган чектүү сандагы кириш маанилери болушу керек. Болбосо, анын бардык баалуулуктарын сактаган таблицаны куруу мүмкүн эмес, анткени чексиз сандагы саптары бар таблица болушу мүмкүн эмес.

мисалы:

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;


Анткени функция үчүн isParent МАТЕРИАЛДАЛГАН деп белгиленген болсо, анда ал үчүн эки ачкыч (топ) бар таблица түзүлөт, анда талаа isParent биринчи ачкыч экинчинин баласы болсо гана туура болот. Бул таблицадагы жазуулардын саны дарактын орточо тереңдигине көбөйтүлгөн топтордун санына барабар болот. Эгер сизге, мисалы, белгилүү бир топтун тукумдарынын санын эсептөө керек болсо, бул функцияны колдонсоңуз болот:

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


SQL сурамында CTE болбойт. Анын ордуна жөнөкөй GROUP BY болот.

Бул механизмди колдонуу менен, зарыл болсо, маалымат базасын оңой эле нормадан чыгара аласыз:

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

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


Функцияны чакырганда дата буйрутма сабы үчүн, индекси бар талаа буйрук саптары менен таблицадан окулат. Буйрутма күнү өзгөргөндө, система өзү автоматтык түрдө саптагы нормадан ажыратылган күндү кайра эсептейт.

артыкчылыктары

Бул механизм эмне үчүн? Классикалык СББларда, кайра жазуу сурамдары жок, иштеп чыгуучу же DBA индекстерди гана өзгөртө алат, статистиканы аныктайт жана суроону пландоочуга аларды кантип аткарууну айта алат (жана КЕҢЕШтер коммерциялык СББларда гана бар). Канчалык аракет кылышпасын, макаладагы биринчи суроону аягына чыгара алышпайт О (бөлүмдөрдүн саны) сурамдарды өзгөртпөстөн же триггерлерди кошпостон. Сунушталган схемада, иштеп чыгуу стадиясында маалыматтарды сактоо түзүмү жана кайсы агрегаттарды колдонуу керектиги жөнүндө ойлонуунун кажети жок. Мунун бардыгын тез эле, түз иштөөдө оңой эле өзгөртүүгө болот.

Иш жүзүндө мындай көрүнөт. Кээ бир адамдар түздөн-түз тапшырманын негизинде логиканы өнүктүрүшөт. Алар алгоритмдерди жана алардын татаалдыгын, аткаруу пландарын, кошулмалардын түрлөрүн жана башка техникалык компоненттерди түшүнүшпөйт. Бул адамдар иштеп чыгуучуларга караганда бизнес-аналитиктер. Андан кийин, мунун баары сыноого же операцияга кирет. Узакка созулган суроо-талаптарды жазууну иштетет. Узакка созулган суроо аныкталганда, башка адамдар (көбүрөөк техникалык - негизинен DBA) кээ бир ортоңку функцияда MATERIALIZEDди иштетүүнү чечишет. Бул жазууну бир аз жайлатат (анткени ал транзакцияда кошумча талааны жаңыртууну талап кылат). Бирок, бул суроо гана эмес, ошондой эле бул функцияны колдонгон башка бардык сурамдар да тездетилген. Ошол эле учурда, кайсы функцияны ишке ашырууну чечүү салыштырмалуу оңой. Эки негизги параметр: мүмкүн болгон киргизүү маанилеринин саны (бул тиешелүү таблицада канча жазуу болот) жана ал башка функцияларда канчалык көп колдонулат.

аналогдору

Заманбап коммерциялык МББлар окшош механизмдерге ээ: ТЕЗ ЖАҢЫРТУУ (Oracle) менен МАТЕРИАЛДАШТЫРЫЛГАН КӨРҮНҮҮ жана ИНДЕКСтелген КӨРҮНҮҮ (Microsoft SQL Server). PostgreSQLде МАТЕРИАЛДАШТЫРЫЛГАН КӨРҮНҮҮ транзакцияда жаңыртылышы мүмкүн эмес, бирок суроо-талап боюнча гана (жана өтө катуу чектөөлөр менен), ошондуктан биз аны эске албайбыз. Бирок аларда бир нече көйгөйлөр бар, алар колдонууну олуттуу чектейт.

Биринчиден, сиз буга чейин кадимки 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 билдирүүдө.

Ошондой эле, сиз тандаган жаңылоо ыкмасы оптималдуу натыйжалуу болбойт, эгерде:

• Аныктоочу суроо ички бириктирүү сыяктуу иш алып барган тышкы бириктирүүнү колдонот. Эгерде аныктоочу суроо ушундай бириктирүүнү камтыса, ички бириктирүүнү камтышы үчүн аныктоочу суроону кайра жазууну карап көрүңүз.
• The 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) белгиленсин.
• The SELECT аныктоочу сурамдагы тилке бир нече базалык таблицалардын мамычалары менен татаал туюнтма боло албайт. Мунун мүмкүн болгон чечүүчү жолу - уяланган материалдашкан көрүнүштү колдонуу.
• The SELECT тизме бардыгын камтышы керек GROUP BY мамычалар.
• Материалдык көрүнүш бир же бир нече алыскы таблицаларга негизделбейт.
• Эгер сиз колдонсоңуз CHAR материалдашкан көрүү журналынын чыпка тилкелериндеги маалымат түрү, башкы сайттын символдор топтому жана материалдашкан көрүнүш бирдей болушу керек.
• Эгерде материалдашкан көрүнүштө төмөндөгүлөрдүн бирине ээ болсо, анда тез жаңылоо кадимки DML кошумчаларында жана түз жүктөөлөрүндө гана колдоого алынат.
  • менен материалдашкан көз караштар MIN or MAX агрегаттар
  • Материалдашкан көз караштар бар SUM(expr) Бирок жок COUNT(expr)
  • Материалдашкан көз караштар жок COUNT(*)

  Мындай материалдашкан көрүнүш жалаң гана кыстаруу материалдашкан көрүнүш деп аталат.

• менен материалдык көрүнүш MAX or MIN жок кылынгандан кийин же аралаш DML билдирүүлөрү жок болсо, тез жаңыртылат WHERE пункт.
  Жок кылуудан же аралаш DMLден кийин максимум/мин тез жаңыртуу кыстаруу үчүн гана иштегидей кыймыл-аракетке ээ эмес. Ал жабыр тарткан топтор үчүн максималдуу/мин маанилерди жок кылат жана кайра эсептейт. Сиз анын натыйжалуулугун билүү керек.
• Аты аталган көрүнүштөр же подсуроолор менен материалдаштырылган көрүнүштөр FROM көз караштар толугу менен бириктирилиши мүмкүн болсо, пунктту тез жаңыртса болот. Кайсы көрүнүштөр бириге тургандыгы тууралуу маалымат алуу үчүн, караңыз Oracle Database SQL тил шилтемеси.
• Эгерде тышкы кошулмалар жок болсо, анда сизде ыктыярдуу тандоолор жана кошулуулар болушу мүмкүн WHERE пункт.
• Сырткы кошулмалар менен материалдаштырылган жалпы көрүнүштөр кадимки DML жана түз жүктөөлөрдөн кийин, сырткы таблицаны гана өзгөрткөндөн кийин тез жаңыланат. Ошондой эле, уникалдуу чектөөлөр ички бириктирүү таблицасынын кошулуу мамычаларында болушу керек. Эгерде сырткы кошулмалар бар болсо, анда бардык кошулмалар аркылуу туташтырылышы керек ANDs жана теңдикти колдонуу керек (=) оператор.
• менен материалдык көз караштар үчүн CUBE, ROLLUP, топтомдорду топтоо же аларды бириктирүү үчүн төмөнкү чектөөлөр колдонулат:
  • The 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 менен материалдашкан көрүнүштөрдү тез жаңыртуу боюнча чектөөлөр

менен материалдашкан көз караштар UNION ALL орнотуу операторун колдойт REFRESH FAST тандоо, эгерде төмөнкү шарттар аткарылса:

• аныктоочу суроо болушу керек UNION ALL жогорку деңгээлдеги оператор.

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

  КӨРҮНҮШҮ view_with_unionall AS (SELECT c.rowid crid, c.cust_id, 2 umarker FROM кардарлар c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker кардарлардан c WHERE c.name_last = "Джонс"); МАТЕРИАЛДАШТЫРЫЛГАН КӨРҮНҮШ ЖАЗУУ unionall_inside_view_mv ТАЛАП БОЮНЧА ТЕЗ ЖАҢЫРТУУ * FROM view_with_unionall;
  

  көрүнүш экенин белгилей кетүү керек view_with_unionall тез жаңылоо талаптарын канааттандырат.

• Ар бир суроо блогундагы UNION ALL суроо агрегаттар менен тез жаңылануучу материалдашкан көрүнүштүн же кошулмалар менен тез жаңылануучу материалдашкан көрүнүштүн талаптарына жооп бериши керек.

  Тиешелүү материалдаштырылган көрүү журналдары тез жаңылануучу материалдашкан көрүнүштүн тиешелүү түрү үчүн талап кылынган таблицаларда түзүлүшү керек.
  Белгилей кетсек, Oracle Database ошондой эле бир таблицанын өзгөчө абалына кошулуу менен материалдашкан көрүнүшкө мүмкүндүк берет ROWID тилкеге ​​киргизилген SELECT тизмеси жана материалдашкан көрүү журналында. Бул көрүнүштүн аныктоочу суроосунда көрсөтүлгөн view_with_unionall.

• The SELECT ар бир суроонун тизмеси а камтууга тийиш UNION ALL маркер, жана UNION ALL мамычанын ар биринде өзүнчө туруктуу сандык же сап мааниси болушу керек UNION ALL бутак. Андан ары, маркер тилкеси ошол эле иреттик абалда пайда болушу керек SELECT ар бир суроо блогунун тизмеси. Кара"UNION ALL Marker жана Query Rewrite» жөнүндө көбүрөөк маалымат алуу үчүн 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 пунктунда же көрүнүштөгү JOIN операциясынын ON пунктунда пайда болушу мүмкүн эмес.
• Көрүнүш аныктамасында колдонулган CLR колдонуучу аныктаган типтердин CLR функциялары жана ыкмалары төмөнкү таблицада көрсөтүлгөндөй белгиленген касиеттерге ээ болушу керек.

  мүлк
  Эскертүү

  ДЕТЕРМИНИСТТИК = ЧЫН
  Microsoft .NET Framework ыкмасынын атрибуту катары ачык жарыяланышы керек.

  ТАК = ЧЫН
  .NET Framework ыкмасынын атрибуту катары ачык жарыяланышы керек.

  DATA ACCESS = SQL ЖОК
  DataAccess атрибутун DataAccessKind.None жана SystemDataAccess атрибутун SystemDataAccessKind.None деп коюу менен аныкталат.

  ТЫШКЫ ЖЕТҮҮ = ЖОК
  Бул сыпат демейки CLR процедуралары үчүн ЖОК деп белгиленет.

• көрүнүштү колдонуу менен түзүлүшү керек WITH SCHEMABINDING тандоо.
• Көрүнүш көрүнүш менен бир маалымат базасында турган базалык таблицаларга гана шилтеме кылышы керек. Көрүнүш башка көз караштарга шилтеме кыла албайт.
• Көрүнүш аныктамасындагы SELECT билдирүүсү төмөнкү Transact-SQL элементтерин камтыбашы керек:

  COUNT
  ROWSET функциялары (OPENDATASOURCE, OPENQUERY, OPENROWSET, ЖАНА OPENXML)
  OUTER кошулат (LEFT, RIGHTже FULL)

  Туунду таблица (а белгилөө менен аныкталган 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

  Сейрек мамычалар топтому
  Inline (TVF) же көп билдирүүлүү таблица-баалуу функциялар (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 Индекстелген көрүнүш камтышы мүмкүн сүзүү мамычалар; бирок, мындай мамычаларды кластердик индекс ачкычына кошууга болбойт.

• If GROUP BY бар болсо, VIEW аныктамасы камтышы керек COUNT_BIG(*) жана камтыбашы керек HAVING. Бул GROUP BY чектөөлөр индекстелген көрүнүш аныктамасына гана тиешелүү. Сурам аларды канааттандырбаса да, анын аткаруу планында индекстелген көрүнүштү колдоно алат GROUP BY чектөөлөр.
• Эгерде көрүнүш аныктамасы а GROUP BY пунктунда, уникалдуу кластердик индекстин ачкычы бөлүмүндө көрсөтүлгөн тилкелерге гана шилтеме кыла алат GROUP BY пункт.

Бул жерде индейлердин катышы жок экени көрүнүп турат, анткени алар муну “биз аз, бирок жакшы кылабыз” схемасы боюнча жасоону чечишкен. Башкача айтканда, алардын кенинде кендери көбүрөөк, бирок алардын жайгашкан жери ачык-айкын. Эң капаланткан нерсе бул чектөө:

Көрүнүш көрүнүш менен бир маалымат базасында турган базалык таблицаларга гана шилтеме кылышы керек. Көрүнүш башка көз караштарга шилтеме кыла албайт.

Биздин терминологияда бул функция башка материалдашкан функцияга кире албайт дегенди билдирет. Бул бүчүрдөгү бардык идеологияны кесип салат.
Ошондой эле, бул чектөө (жана андан ары текстте) колдонуу учурларын абдан азайтат:

Көрүнүш аныктамасындагы SELECT билдирүүсү төмөнкү Transact-SQL элементтерин камтыбашы керек:

COUNT
ROWSET функциялары (OPENDATASOURCE, OPENQUERY, OPENROWSET, ЖАНА OPENXML)
OUTER кошулат (LEFT, RIGHTже FULL)

Туунду таблица (а белгилөө менен аныкталган 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

Сейрек мамычалар топтому
Inline (TVF) же көп билдирүүлүү таблица-баалуу функциялар (MSTVF)
OFFSET

CHECKSUM_AGG

Тышкы кошулуулар, СОЮЗ, ORDER BY жана башкаларга тыюу салынат. Колдонулбай турган нерсени эмес, эмнени колдонууга болорун аныктоо оңой болгондур. Тизме, балким, бир топ кыскараак болмок.

Кыскача айтканда: LGPL технологиясындагы ар бир (коммерциялык эмес) DBMS менен эч кимге (бир логикалык эмес, техникалык жактан кошпогондо) чектөөлөрдүн чоң топтому. Бирок бул механизмди реляциялык логикада ишке ашыруу сүрөттөлгөн функционалдык логикага караганда бир аз татаалыраак экенин белгилей кетүү керек.

Реализация

Бул кандай иштейт? PostgreSQL "виртуалдык машина" катары колдонулат. Ичинде суроолорду түзгөн татаал алгоритм бар. Бул жерде Баштапкы код. Жана бир топ ifs менен эвристиканын чоң жыйындысы гана жок. Демек, сизде окууга бир нече ай болсо, архитектураны түшүнүүгө аракет кылсаңыз болот.

Ал натыйжалуу иштейби? Абдан эффективдүү. Тилекке каршы, муну далилдөө кыйын. Мен бир гана айта алам, эгерде сиз чоң тиркемелерде болгон миңдеген суроо-талаптарды эске алсаңыз, анда алар орточо эсеп менен жакшы иштеп чыгуучунун суроолоруна караганда натыйжалуураак. Мыкты SQL программисти каалаган суроону натыйжалуураак жаза алат, бирок миңдеген суроо менен анын аны аткарууга мотивациясы да, убактысы да болбойт. Мен азыр эффективдүүлүктү далилдей турган бир гана нерсе - бул DBMSде курулган платформада бир нече долбоорлор иштеп жатат. ERP системалары, миңдеген ар кандай МАТЕРИАЛДАШТЫРЫЛГАН функциялары бар, миңдеген колдонуучулар жана жүздөгөн миллиондогон жазуулары бар терабайттык маалымат базалары кадимки эки процессорлуу серверде иштейт. Бирок, кимдир бирөө жүктөп алуу менен натыйжалуулугун текшере / жокко чыгара алат платформа жана PostgreSQL, күйгүзүлдү SQL сурамдарын жазуу жана ал жердеги логиканы жана маалыматтарды өзгөртүүгө аракет кылуу.

Кийинки макалаларда мен функцияларга кантип чектөөлөрдү коюу, өзгөртүү сессиялары менен иштөө жана башка көптөгөн нерселер жөнүндө сүйлөшөм.

Source: www.habr.com