ProHoster > Blog > Administratioun > Balancing schreift a liest an enger Datebank

Balancing schreift a liest an enger Datebank

Balancing schreift a liest an enger Datebank
An der viregter Artikel Ech hunn d'Konzept an d'Ëmsetzung vun enger Datebank beschriwwen op Basis vu Funktiounen, anstatt Dëscher a Felder wéi an relational Datenbanken. Et gëtt vill Beispiller déi d'Virdeeler vun dëser Approche iwwer déi klassesch weisen. Vill hunn se net iwwerzeegend genuch fonnt.

An dësem Artikel wäert ech weisen, wéi dëst Konzept Iech erlaabt Iech séier a bequem Schreiwen a Liesen an d'Datebank ze balanséieren ouni Ännerung vun der Operatiounslogik. Ähnlech Funktionalitéit gouf versicht a modern kommerziellen DBMSs (besonnesch Oracle a Microsoft SQL Server) implementéiert ze ginn. Um Enn vum Artikel wäert ech weisen datt dat wat se gemaach hunn, fir et mild ze soen, net ganz gutt geklappt huet.

Beschreiwung

Wéi virdrun, fir e bessert Verständnis, fänken ech d'Beschreiwung mat Beispiller un. Loosst eis soen datt mir Logik implementéiere mussen, déi eng Lëscht vun Departementer mat der Zuel vun de Mataarbechter an hirem Gesamtgehalt zréckginn.

An enger funktioneller Datebank géif et esou ausgesinn:

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

D'Komplexitéit vun der Ausféierung vun dëser Ufro an all DBMS wäert gläichwäerteg sinn O (Zuel vun de Mataarbechter)well dës Berechnung erfuerdert de ganzen Dësch vun de Mataarbechter ze scannen an se dann no Departement ze gruppéieren. Et gëtt och e puer kleng (mir gleewen, datt et vill méi Mataarbechter wéi Departementer sinn) Zousaz ofhängeg vun der gewielter plangen O (Log Zuel vun Mataarbechter) oder O (Zuel vun Departementer) fir Gruppéierung a sou weider.

Et ass kloer datt d'Ausféierungsoverhead a verschiddene DBMSs anescht ka sinn, awer d'Komplexitéit wäert op kee Fall änneren.

An der proposéierter Ëmsetzung generéiert de funktionnelle DBMS eng Ënnerquery déi déi erfuerderlech Wäerter fir d'Departement berechent, an dann e JOIN mat der Departementstabell mécht fir den Numm ze kréien. Wéi och ëmmer, fir all Funktioun, wann Dir deklaréiert, ass et méiglech e spezielle MATERIALIZED Marker ze setzen. De System erstellt automatesch en entspriechend Feld fir all esou Funktioun. Wann Dir de Wäert vun enger Funktioun ännert, ännert de Wäert vum Feld och an der selwechter Transaktioun. Wann Dir op dës Funktioun kënnt, gëtt de virberechent Feld zougänglech.

Besonnesch wann Dir MATERIALIZED fir Funktiounen setzt zielen Employéen и GehaltSum, da ginn zwee Felder op den Dësch mat der Lëscht vun den Departementer bäigefüügt, déi d'Zuel vun de Mataarbechter an hiren Gesamtgehalt späicheren. All Kéier wann et eng Ännerung vun de Mataarbechter, hir Paien oder Departementer verbonnen ass, ännert de System automatesch d'Wäerter vun dëse Felder. Déi uewe genannte Ufro wäert Zougang zu dëse Felder direkt kréien a gëtt ausgefouert O (Zuel vun Departementer).

Wat sinn d'Restriktiounen? Nëmmen eng Saach: sou eng Funktioun muss eng endlech Unzuel vun Inputwäerter hunn, fir déi säi Wäert definéiert ass. Soss wäert et onméiglech sinn eng Tabell ze bauen déi all seng Wäerter späichert, well et kann net en Dësch mat enger onendlecher Zuel vu Reihen sinn.

Beispill:

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

Dës Funktioun ass fir eng onendlech Zuel vu Wäerter vun der Zuel N definéiert (zum Beispill, all negativ Wäert ass gëeegent). Dofir kënnt Dir MATERIALIZED net drop setzen. Also dëst ass eng logesch Begrenzung, net eng technesch (dat ass, net well mir et net konnten ëmsetzen). Soss ginn et keng Restriktiounen. Dir kënnt Gruppéierungen, Sortéierung, AN an ODER, PARTITION, Rekursioun, etc.

Zum Beispill, am Problem 2.2 vum viregten Artikel, kënnt Dir MATERIALIZED op béid Funktiounen setzen:

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;

De System selwer wäert een Dësch mat Typ Schlësselen schafen Client, Produit и INTEGER, füügt zwee Felder derbäi a aktualiséieren d'Feldwäerter an hinnen mat all Ännerungen. Wann weider Uriff op dës Funktiounen gemaach ginn, gi se net berechent, mä éischter d'Wäerter ginn aus de entspriechende Felder gelies.

Mat dësem Mechanismus kënnt Dir zum Beispill Rekursiounen (CTE) bei Ufroen entgoen. Betruecht besonnesch Gruppen déi e Bam bilden mat der Kand/Elter-Relatioun (all Grupp huet e Link op seng Elteren):

parent = DATA Group (Group);

An enger funktioneller Datebank kann d'Rekursiounslogik wéi follegt spezifizéiert ginn:

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;

Zënter fir d'Funktioun ass Elterendeel ass markéiert MATERIALIZED, da gëtt en Dësch mat zwee Schlësselen (Gruppen) dofir erstallt, an deem d'Feld ass Elterendeel wäert nëmme richteg sinn wann den éischte Schlëssel e Kand vun der zweeter ass. D'Zuel vun den Entréen an dëser Tabell wäert d'selwecht sinn wéi d'Zuel vun de Gruppen multiplizéiert mat der duerchschnëttlecher Déift vum Bam. Wann Dir braucht, zum Beispill, d'Zuel vun den Nokommen vun enger bestëmmter Grupp ze zielen, kënnt Dir dës Funktioun benotzen:

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

Et gëtt keng CTE an der SQL Ufro. Amplaz gëtt et eng einfach GROUP BY.

Mat dësem Mechanismus kënnt Dir d'Datebank och einfach denormaliséieren wann néideg:

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

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

Wann Dir eng Funktioun rufft Datum fir d'Bestellungslinn gëtt d'Feld fir deen en Index gëtt aus der Tabell mat Bestellungslinnen gelies. Wann d'Bestellungsdatum ännert, wäert de System selwer automatesch den denormaliséierten Datum an der Linn nei berechnen.

Virdeeler

Wat ass dee ganze Mechanismus fir? A klassesche DBMSen, ouni Ufroen ëmzeschreiwen, kann en Entwéckler oder DBA nëmmen Indexen änneren, Statistiken bestëmmen an dem Ufroplaner soen wéi se se ausféieren (an HINTs sinn nëmme verfügbar a kommerziellen DBMSs). Egal wéi schwéier se probéieren, si kënnen net déi éischt Ufro am Artikel fäerdeg maachen O (Zuel vun Departementer) ouni Ufroen z'änneren oder Trigger derbäi ze ginn. Am proposéierte Schema, an der Entwécklungsstadium musst Dir net iwwer d'Datespeicherstruktur denken a wéi eng Aggregatiounen ze benotzen. All dëst kann einfach op der Flucht geännert ginn, direkt an der Operatioun.

An der Praxis gesäit et esou aus. E puer Leit entwéckelen Logik direkt baséiert op der Aufgab op der Hand. Si verstinn net Algorithmen an hir Komplexitéit, nach Ausféierungspläng, nach Aarte vu Joint, nach all aner technesch Komponent. Dës Leit si méi Geschäftsanalytiker wéi Entwéckler. Da geet dat alles an Testen oder Operatioun. Erméiglecht d'Protokolléiere vu laangfristeg Ufroen. Wann eng laang Ufro festgestallt gëtt, dann entscheeden aner Leit (méi technesch - am Wesentlechen DBA) MATERIALIZED op eng Zwëschenfunktioun z'aktivéieren. Dëst verlangsamt d'Opnahm e bëssen (well et erfuerdert d'Aktualiséierung vun engem zousätzleche Feld an der Transaktioun). Wéi och ëmmer, net nëmmen dës Ufro ass wesentlech beschleunegt, awer och all déi aner déi dës Funktioun benotzen. Zur selwechter Zäit ass et relativ einfach ze entscheeden wéi eng Funktioun ze materialiséieren. Zwee Haaptparameter: d'Zuel vu méiglechen Inputwäerter (dëst ass wéivill Opzeechnungen an der entspriechender Tabell sinn), a wéi dacks et an anere Funktiounen benotzt gëtt.

Analoguen

Modern kommerziell DBMSs hunn ähnlech Mechanismen: MATERIALIZED VIEW mat FAST REFRESH (Oracle) an INDEXED VIEW (Microsoft SQL Server). Am PostgreSQL, MATERIALIZED VIEW kann net an enger Transaktioun aktualiséiert ginn, awer nëmmen op Ufro (a souguer mat ganz strikte Restriktiounen), sou datt mir et net berücksichtegen. Awer si hunn e puer Probleemer déi hir Notzung wesentlech limitéieren.

Als éischt kënnt Dir nëmmen d'Materialiséierung aktivéieren wann Dir schonn eng regulär VIEW erstallt hutt. Soss musst Dir déi verbleiwen Ufroen iwwerschreiwe fir op déi nei erstallt Vue ze kommen fir dës Materialiséierung ze benotzen. Oder loosst alles sou wéi et ass, awer et wäert op d'mannst net effikass sinn wann et bestëmmte scho virberechent Donnéeën ass, awer vill Ufroen benotzen se net ëmmer, awer recalculéieren se.

Zweetens, si hunn eng grouss Zuel vu Restriktiounen:

entscheet

5.3.8.4 Allgemeng Restriktiounen op Fast Refresh

Déi definéierend Ufro vun der materialiséierter Vue ass limitéiert wéi follegt:

  • Déi materialiséiert Vue däerf keng Referenzen op net widderhuelend Ausdréck enthalen wéi SYSDATE an ROWNUM.
  • Déi materialiséiert Vue däerf keng Referenzen op enthalen RAW or LONG RAW daten Zorte.
  • Et kann net enthalen a SELECT Lëscht subquery.
  • Et kann net analytesch Funktiounen enthalen (zum Beispill, RANK) an SELECT Klausel.
  • Et kann net en Dësch Referenz op déi eng XMLIndex Index definéiert ass.
  • Et kann net enthalen a MODEL Klausel.
  • Et kann net enthalen a HAVING Klausel mat enger Ënnerquery.
  • Et kann net nested Ufroen enthalen déi hunn ANY, ALL, oder NOT EXISTS.
  • Et kann net enthalen a [START WITH …] CONNECT BY Klausel.
  • Et kann net méi Detailer Dëscher op verschiddene Siten enthalen.
  • ON COMMIT materialiséiert Meenungen kënnen net Remote Detail Dëscher hunn.
  • Nested materialiséiert Meenungen mussen e Bäitrëtt oder aggregéiert hunn.
  • Materialiséiert Bäiträg Meenung a materialiséiert aggregéiert Meenung mat engem GROUP BY Klausel kann net aus engem Index-organiséiert Dësch wielen.

5.3.8.5 Restriktiounen op Fast Refresh op materialiséierte Vue mat Joins Nëmmen

Definéieren Ufroe fir materialiséierte Meenungen nëmme mat Joins a keng Aggregaten hunn déi folgend Restriktiounen op séier Erfrëschung:

  • All Restriktiounen vun «Allgemeng Restriktiounen op Fast Refresh".
  • Si kënnen net hunn GROUP BY Klauselen oder Aggregaten.
  • Rowids vun all Dëscher an der FROM Lëscht muss an der schéngen SELECT Lëscht vun der Ufro.
  • Materialiséiert Hibléck Logbicher muss existéieren mat rowids fir all Basis Dëscher an der FROM Lëscht vun der Ufro.
  • Dir kënnt net eng séier erfrëschbar materialiséiert Vue aus multiple Dëscher erstellen mat einfache Join, déi eng Objekttyp Kolonn an der SELECT Ausso.

Och d'Erfrëschungsmethod déi Dir wielt wäert net optimal effizient sinn wann:

  • Déi definéierend Ufro benotzt e baussenzege Bäitrëtt, dee sech wéi en banneschten Bäitrëtt behält. Wann déi definéierend Ufro esou e Join enthält, betruecht d'Definitiounsufro ëmzeschreiwen fir en banneschten Join ze enthalen.
  • d' SELECT Lëscht vun der materialiséierter Vue enthält Ausdréck op Spalten aus MÉI Dëscher.

5.3.8.6 Restriktiounen op Fast Refresh op materialiséierte Vue mat Aggregaten

Definéieren Ufroe fir materialiséiert Meenungen mat Aggregaten oder Join hunn déi folgend Restriktiounen fir séier Erfrëschung:

Fast Refresh gëtt fir béid ënnerstëtzt ON COMMIT an ON DEMAND materialiséiert Meenungen, awer déi folgend Restriktiounen gëllen:

  • All Dëscher an der materialiséierter Vue musse materialiséierte Vue Logbicher hunn, an déi materialiséiert Vue Logbicher mussen:
    • Enthält all Kolonnen aus der Tabell, déi an der materialiséierter Vue referenzéiert ass.
    • Spezifizéieren mat ROWID an INCLUDING NEW VALUES.
    • Gitt de SEQUENCE Klausel wann den Dësch erwaart gëtt eng Mëschung vun Inserts / Direct-loads, Läschen an Updates ze hunn.

  • nëmmen SUM, COUNT, AVG, STDDEV, VARIANCE, MIN an MAX gi fir séier Erfrëschung ënnerstëtzt.
  • COUNT(*) muss spezifizéiert ginn.
  • Aggregéiert Funktiounen mussen nëmmen als äusseren Deel vum Ausdrock optrieden. Dat ass, Aggregaten wéi AVG(AVG(x)) or AVG(x)+ AVG(x) sinn net erlaabt.
  • Fir all Aggregat wéi z AVG(expr), déi entspriechend COUNT(expr) muss präsent sinn. Oracle recommandéiert dat SUM(expr) spezifizéiert ginn.
  • If VARIANCE(expr) or STDDEV(expr) spezifizéiert ass, COUNT(expr) an SUM(expr) muss spezifizéiert ginn. Oracle recommandéiert dat SUM(expr *expr) spezifizéiert ginn.
  • d' SELECT Kolonn an der definéierender Ufro kann net e komplexen Ausdrock mat Spalten aus multiple Basistabellen sinn. Eng méiglech Léisung fir dëst ass eng nestéiert materialiséiert Vue ze benotzen.
  • d' SELECT Lëscht muss all enthalen GROUP BY Sailen.
  • Déi materialiséiert Vue baséiert net op enger oder méi Ferntabellen.
  • Wann Dir e benotzt CHAR Datentyp an de Filtersäulen vun engem materialiséierte View Log, d'Zeechensätz vum Master Site an der materialiséierter Vue mussen d'selwecht sinn.
  • Wann déi materialiséiert Vue ee vun de folgenden huet, da gëtt séier Erfrëschung nëmmen op konventionell DML-Inserts an direkt Lasten ënnerstëtzt.
    • Materialiséiert Meenung mat MIN or MAX aggregéiert
    • Materialiséiert Meenung déi hunn SUM(expr) awer nee COUNT(expr)
    • Materialiséiert Meenung ouni COUNT(*)

    Sou eng materialiséiert Vue gëtt eng Insert-nëmmen materialiséierter Vue genannt.

  • Eng materialiséiert Vue mat MAX or MIN ass séier erfrëschtbar no Läschen oder gemëschten DML Aussoen, wann et keng WHERE Klausel.
    De Max / min schnellen Erfrëschung nom Läschen oder gemëschten DML huet net datselwecht Verhalen wéi den Insert-nëmmen Fall. Et läscht a berechent d'Max / min Wäerter fir déi betraff Gruppen nei. Dir musst bewosst seng Leeschtung Impakt ginn.
  • Materialiséiert Meenungen mat genannt Meenungen oder subqueries an der FROM Klausel ka séier erfrëscht ginn wann d'Meenungen komplett fusionéiert kënne ginn. Fir Informatiounen iwwer déi Meenungen fusionéieren, kuckt Oracle Datebank SQL Sprooch Referenz.
  • Wann et keng baussenzege Bäiträg, Dir hutt vläicht arbiträr Auswiel an dobäi an der WHERE Klausel.
  • Materialiséiert aggregéiert Vue mat baussenzege Joint si séier erfrëschbar no konventionell DML an direkten Lasten, virausgesat datt nëmmen de baussenzege Dësch geännert gouf. Och eenzegaarteg Aschränkungen musse existéieren op de Joint Sailen vun der bannenzeger Joint Tabell. Wann et baussenzege Joint sinn, mussen all Joints duerch verbonne sinn ANDs a muss d'Gläichheet benotzen (=) Bedreiwer.
  • Fir materialiséiert Meenung mat CUBE, ROLLUP, Gruppéierungssätz oder Konkatenatioun vun hinnen, gëllen déi folgend Restriktiounen:
    • d' SELECT Lëscht soll Gruppéierungsënnerscheeder enthalen, déi entweder e sinn GROUPING_ID Funktioun op all GROUP BY Ausdréck bzw GROUPING Fonctiounen eent fir all GROUP BY Ausdrock. Zum Beispill, wann de GROUP BY Klausel vun der materialiséierter Vue ass "GROUP BY CUBE(a, b)", dann de SELECT Lëscht soll entweder "GROUPING_ID(a, b)» oder «GROUPING(a) AND GROUPING(b)» fir déi materialiséiert Vue séier erfrëschbar ze sinn.
    • GROUP BY sollt net zu duplizéierte Gruppéierungen resultéieren. Zum Beispill, "GROUP BY a, ROLLUP(a, b)"ass net séier erfrëschbar well et zu duplizéierte Gruppéierungen resultéiert"(a), (a, b), AND (a)".

5.3.8.7 Restriktiounen op Fast Refresh op Materialized Meenung mat UNION ALL

Materialiséiert Meenung mat der UNION ALL setzen Bedreiwer Ënnerstëtzung der REFRESH FAST Optioun wann déi folgend Konditiounen erfëllt sinn:

  • Déi definéierend Ufro muss den UNION ALL Bedreiwer um Top Niveau.

    d' UNION ALL Bedreiwer kann net an enger Ënnerquery agebaut ginn, mat enger Ausnam: D' UNION ALL kann an engem subquery am FROM Klausel virausgesat datt déi definéierend Ufro vun der Form ass SELECT * FROM (kuckt oder subquery mat UNION ALL) wéi am folgende Beispill:

    CREATE VIEW view_with_unionall AS (SELECT c.rowid crid, c.cust_id, 2 umarker FROM clients c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker FROM clients c WHERE c.cust_last_name = 'Jones'); CREATE MATERIALIZED VIEW unionall_inside_view_mv REFRESH FAST ON DEMAND AS SELECT * FROM view_with_unionall;

    Notéiert datt d'Vue view_with_unionall entsprécht den Ufuerderunge fir séier Erfrëschung.

  • All Ufro Block an der UNION ALL Ufro muss d'Ufuerderunge vun enger séier erfrëschbarer materialiséierter Vue mat Aggregaten oder enger séier erfrëschbarer materialiséierter Vue mat Joint erfëllen.

    Déi entspriechend materialiséierter Vue Logbicher mussen op den Dëscher erstallt ginn wéi néideg fir déi entspriechend Aart vu séier erfrëschbare materialiséierter Vue.
    Bedenkt datt d'Oracle Datebank och de spezielle Fall vun engem eenzegen Dësch materialiséierte Vue erlaabt mat Joint nëmmen déi ROWID Kolonn ass an der abegraff ginn SELECT Lëscht an am materialiséierte View Log. Dëst gëtt an der definéierender Ufro vun der Vue gewisen view_with_unionall.

  • d' SELECT Lëscht vun all Ufro muss eng enthalen UNION ALL Marker, an UNION ALL Kolonn muss e markéierte konstante numeresche oder Stringwäert an all hunn UNION ALL branch. Weider muss d'Markéierer Kolonn an der selwechter Uerdnung Positioun an der schéngen SELECT Lëscht vun all Ufro Block. Kuckt "UNION ALL Marker a Query Rewrite» fir méi Informatiounen iwwer UNION ALL Markéierer.
  • E puer Features wéi äusseren Joins, Insert-nëmmen aggregéiert materialiséierter Vue Ufroen a Ferntabellen ginn net ënnerstëtzt fir materialiséiert Vue mat UNION ALL. Notéiert awer datt materialiséiert Meenungen, déi an der Replikatioun benotzt ginn, déi keng Joints oder Aggregaten enthalen, séier erfrëscht kënne ginn wann UNION ALL oder Remote Dëscher ginn benotzt.
  • De Kompatibilitéitsinitialiséierungsparameter muss op 9.2.0 oder méi héich gesat ginn fir eng séier erfrëschbar materialiséiert Vue ze kreéieren mat UNION ALL.

Ech wëll Oracle Fans net beleidegen, awer no hirer Lëscht vu Restriktiounen beurteelen, schéngt et datt dëse Mechanismus net am allgemenge Fall geschriwwe gouf, mat enger Aart vu Modell, awer vun Dausende vun Indianer, wou jidderee d'Méiglechkeet kritt huet hir eege Branche schreiwen, a jidderee vun hinnen huet gemaach wat hie konnt.an huet. Dëse Mechanismus fir richteg Logik ze benotzen ass wéi duerch e Minefeld ze goen. Dir kënnt zu all Moment eng Minière kréien andeems Dir eng vun den net offensichtleche Restriktiounen trefft. Wéi et funktionnéiert ass och eng separat Fro, awer et ass iwwer den Ëmfang vun dësem Artikel.

Microsoft SQL Server

Weider Viraussetzungen

Zousätzlech zu de SET Optiounen an deterministesche Funktiounsufuerderunge mussen déi folgend Ufuerderunge erfëllt sinn:

  • De Benotzer deen ausféiert CREATE INDEX muss de Besëtzer vun der Vue ginn.
  • Wann Dir den Index erstellt, gëtt de IGNORE_DUP_KEY Optioun muss op OFF gesat ginn (de Standardastellung).
  • Dëscher mussen duerch zwee-Deel Nimm referenzéiert ginn, Schema.Dësch Numm an der Vue Definitioun.
  • Benotzerdefinéiert Funktiounen, déi an der Vue referenzéiert sinn, mussen erstallt ginn andeems Dir de benotzt WITH SCHEMABINDING Optioun.
  • All Benotzerdefinéiert Funktiounen, déi an der Vue referenzéiert sinn, musse vun zwee-Deel Nimm referenzéiert ginn, ..
  • D'Datenzougangseigenschafte vun enger Benotzerdefinéierter Funktioun muss sinn NO SQL, an externen Zougang Propriétéit muss NO.
  • Gemeinsam Sprooch Runtime (CLR) Funktiounen kann an der Auswiel Lëscht vun der Vue schéngen, mee kann net Deel vun der Definitioun vun der clustered Index Schlëssel ginn. CLR Funktiounen kënnen net an der WHERE Klausel vun der Vue oder der ON Klausel vun enger JOIN Operatioun an der Vue erschéngen.
  • CLR Funktiounen a Methode vun CLR Benotzer-definéiert Typen an der Vue Definitioun benotzt muss d'Eegeschafte Formatioun wéi an der folgender Tabell gewisen.

    Property
    Notéiert

    DETERMINISTIC = TRUE
    Muss explizit als Attribut vun der Microsoft .NET Framework Method deklaréiert ginn.

    PRÉZIS = TRUE
    Muss explizit als Attribut vun der .NET Framework Method deklaréiert ginn.

    DATAZOUGANG = KENG SQL
    Bestëmmt andeems Dir DataAccess Attribut op DataAccessKind.None a SystemDataAccess Attribut op SystemDataAccessKind.None setzt.

    EXTERNEN ZOUGANG = NEE
    Dëse Besëtz ass Standard op NEE fir CLR Routinen.

  • D'Vue muss erstallt ginn andeems Dir de WITH SCHEMABINDING Optioun.
  • D'Vue muss nëmmen Basis Dëscher referenzéieren déi an der selwechter Datebank wéi d'Vue sinn. D'Vue kann net aner Meenungen referenzéieren.
  • D'SELECT Ausso an der Vue Definitioun däerf net déi folgend Transact-SQL Elementer enthalen:

    COUNT
    ROWSET Funktiounen (OPENDATASOURCE, OPENQUERY, OPENROWSET, AN OPENXML)
    OUTER bäitrieden (LEFT, RIGHT, oder FULL)

    Ofgeleet Tabell (definéiert andeems Dir a SELECT Ausso an der FROM Klausel)
    Selwer bäitrieden
    Spezifizéieren Spalten duerch benotzt SELECT * or SELECT <table_name>.*

    DISTINCT
    STDEV, STDEVP, VAR, VARP, oder AVG
    Common Table Expression (CTE)

    fléien1, Text, ntext, Bild, XML, oder filestream Saile
    Ënnerquery
    OVER Klausel, déi Ranking oder aggregéiert Fënsterfunktiounen enthält

    Volltext Prädikate (CONTAINS, FREETEXT)
    SUM Funktioun déi en nullbaren Ausdrock verweist
    ORDER BY

    CLR Benotzerdefinéiert aggregéiert Funktioun
    TOP
    CUBE, ROLLUP, oder GROUPING SETS Betreiber

    MIN, MAX
    UNION, EXCEPT, oder INTERSECT Betreiber
    TABLESAMPLE

    Dësch Verännerlechen
    OUTER APPLY or CROSS APPLY
    PIVOT, UNPIVOT

    Sparse Kolonn Sets
    Inline (TVF) oder Multi-Statement Table-valued Funktiounen (MSTVF)
    OFFSET

    CHECKSUM_AGG

    1 Déi indexéiert Vue kann enthalen fléien Sailen; allerdéngs, esou Saile kënnen net am clustered Index Schlëssel abegraff ginn.

  • If GROUP BY präsent ass, muss d'VIEW Definitioun enthalen COUNT_BIG(*) a däerf net enthalen HAVING. Dës GROUP BY Restriktiounen sinn applicabel nëmmen op der indexéiert Vue Definitioun. Eng Ufro kann eng indexéiert Vue a sengem Ausféierungsplang benotzen, och wann et dës net zefriddestellt GROUP BY Restriktiounen.
  • Wann der Vue Definitioun enthält eng GROUP BY Klausel, de Schlëssel vum eenzegaartege clustered Index kann nëmmen d'Säulen referenzéieren, déi an der spezifizéiert sinn GROUP BY Klausel.

Et ass kloer hei datt d'Indianer net involvéiert waren, well se decidéiert hunn et no dem Schema ze maachen "Mir wäerte wéineg maachen, awer gutt." Dat ass, si hunn méi Minièren um Terrain, mä hir Plaz ass méi transparent. Déi enttäuschendst Saach ass dës Begrenzung:

D'Vue muss nëmmen Basis Dëscher referenzéieren déi an der selwechter Datebank wéi d'Vue sinn. D'Vue kann net aner Meenungen referenzéieren.

An eiser Terminologie heescht dat datt eng Funktioun net op eng aner materialiséiert Funktioun zougräifen kann. Dëst schneit all Ideologie am Knospe erof.
Och dës Begrenzung (a weider am Text) reduzéiert d'Benotzungsfäll staark:

D'SELECT Ausso an der Vue Definitioun däerf net déi folgend Transact-SQL Elementer enthalen:

COUNT
ROWSET Funktiounen (OPENDATASOURCE, OPENQUERY, OPENROWSET, AN OPENXML)
OUTER bäitrieden (LEFT, RIGHT, oder FULL)

Ofgeleet Tabell (definéiert andeems Dir a SELECT Ausso an der FROM Klausel)
Selwer bäitrieden
Spezifizéieren Spalten duerch benotzt SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, oder AVG
Common Table Expression (CTE)

fléien1, Text, ntext, Bild, XML, oder filestream Saile
Ënnerquery
OVER Klausel, déi Ranking oder aggregéiert Fënsterfunktiounen enthält

Volltext Prädikate (CONTAINS, FREETEXT)
SUM Funktioun déi en nullbaren Ausdrock verweist
ORDER BY

CLR Benotzerdefinéiert aggregéiert Funktioun
TOP
CUBE, ROLLUP, oder GROUPING SETS Betreiber

MIN, MAX
UNION, EXCEPT, oder INTERSECT Betreiber
TABLESAMPLE

Dësch Verännerlechen
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Sparse Kolonn Sets
Inline (TVF) oder Multi-Statement Table-valued Funktiounen (MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOINS, UNION, ORDER BY an anerer sinn verbueden. Et wier vläicht méi einfach gewiescht ze spezifizéieren wat benotzt ka ginn anstatt wat net benotzt ka ginn. D'Lëscht wier wahrscheinlech vill méi kuerz.

Zesummefaassend: e grousse Set vu Restriktiounen an all (loosst eis kommerziell) DBMS vs keng (mat Ausnam vun enger logescher, net technescher) an der LGPL Technologie. Wéi och ëmmer, et sollt bemierkt datt d'Ëmsetzung vun dësem Mechanismus an der relationaler Logik e bësse méi schwéier ass wéi an der beschriwwener funktioneller Logik.

Ëmsetzung

Wéi funktionéiert et? PostgreSQL gëtt als "virtuell Maschinn" benotzt. Et gëtt e komplexe Algorithmus dobannen deen Ufroen baut. Hei Quell. An et gëtt net nëmmen e grousse Set vun Heuristike mat enger Rëtsch Ifs. Also, wann Dir e puer Méint hutt fir ze studéieren, kënnt Dir probéieren d'Architektur ze verstoen.

Wierkt et effektiv? Ganz effektiv. Leider ass dëst schwéier ze beweisen. Ech kann nëmme soen datt wann Dir d'Dausende vun Ufroen berücksichtegt, déi a grousse Applikatiounen existéieren, da si se am Duerchschnëtt méi effizient wéi déi vun engem gudden Entwéckler. En exzellente SQL Programméierer kann all Ufro méi effizient schreiwen, awer mat dausend Ufroen huet hien einfach net d'Motivatioun oder d'Zäit et ze maachen. Dat eenzegt wat ech elo als Beweis vun der Effektivitéit zitéieren kann ass datt verschidde Projete schaffen op der Plattform op dëser DBMS gebaut ERP Systemer, déi Dausende vu verschiddene MATERIALIZED Funktiounen hunn, mat Dausende vu Benotzer an Terabyte-Datenbanken mat Honnerte vu Millioune Rekorder déi op engem normale Zwee-Prozessor-Server lafen. Wéi och ëmmer, jiddereen kann d'Effizienz iwwerpréiwen / refuséieren andeems Dir erofluet Plattform an PostgreSQL, opzemaachen loggt SQL Ufroen a probéiert d'Logik an d'Donnéeën do z'änneren.

An den folgenden Artikelen wäert ech och schwätzen iwwer wéi Dir Restriktiounen op Funktiounen asetzen kënnt, mat Changement Sessiounen schaffen, a vill méi.

Source: will.com

Setzt e Commentaire