Équilibrage des écritures et des lectures dans la base de données

Dans l'article précédent article J'ai décrit le concept et la mise en œuvre d'une base de données basée sur des fonctions plutôt que sur des tables et des champs comme dans les bases de données relationnelles. De nombreux exemples ont été fournis pour montrer les avantages de cette approche par rapport à la classique. Beaucoup les ont jugés peu convaincants.

Dans cet article, je vais montrer comment ce concept permet d'équilibrer rapidement et facilement les écritures et les lectures dans la base de données sans modifier la logique de fonctionnement. Une fonctionnalité similaire a été tentée dans des SGBD commerciaux modernes (en particulier, Oracle et Microsoft SQL Server). À la fin de l'article, je montrerai les résultats obtenus, qui, pour le dire poliment, ne sont pas très concluants.

Description

Comme auparavant, pour une meilleure compréhension, je commencerai la description par des exemples. Supposons que nous devions mettre en œuvre une logique qui retourne une liste de départements avec le nombre d'employés et leur salaire total.

Dans une base de données fonctionnelle, cela ressemblerait à ceci :

CLASS Département ‘Département’;
name ‘Dénomination’ = CHAÎNE DE DONNÉES[100] (Département);

CLASS Employee ‘Employé’;
department ‘Département’ = DATA Department (Employee);
salary ‘Salaire’ = DATA NUMERIC[10,2] (Employee);

countEmployees ‘Nombre d’employés’ (Department d) = 
    GROUPE SOMME 1 SI department(Employee e) = d;
salarySum ‘Salaire total’ (Department d) = 
    GROUPE SOMME salary(Employee e) SI department(e) = d;

SELECT name(Department d), countEmployees(d), salarySum(d);

La complexité de l'exécution de cette requête dans n'importe quel SGBD sera équivalente à O(nombre d'employés), car pour ce calcul, il faut parcourir l'ensemble de la table des employés, puis les regrouper par département. Il y aura également un léger ajout (en supposant que le nombre d’employés est bien plus élevé que le nombre de départements) en fonction du plan choisi. O(log nombre d'employés) ou O(nombre de départements) pour le regroupement et autres.

Il est clair que les frais généraux peuvent varier d'un SGBD à l'autre, mais la complexité ne changera pas.

Dans l'implémentation proposée, le SGBD fonctionnel générera une sous-requête qui calculera les valeurs nécessaires par département, puis effectuera un JOIN avec la table des départements pour obtenir le nom. Cependant, pour chaque fonction lors de la déclaration, il est possible de définir un marqueur spécial MATERIALIZED. Le système créera automatiquement un champ correspondant pour chaque telle fonction. Lorsque la valeur de la fonction change, la valeur du champ changera également dans la même transaction. Lors de l'appel à cette fonction, l'accès se fera déjà au champ pré-calculé.

En particulier, si l'on définit MATERIALIZED pour les fonctions countEmployees et salarySum, deux champs seront ajoutés à la table des départements, dans lesquels seront stockés le nombre d'employés et leur salaire total. Chaque fois qu'il y a un changement concernant les employés, leurs salaires ou leur appartenance aux départements, le système mettra automatiquement à jour les valeurs de ces champs. La requête ci-dessus accédera directement à ces champs et s'exécutera en O(nombre de départements).

Quelles sont les limitations ? Une seule : une telle fonction doit avoir un nombre fini de valeurs d'entrée pour lesquelles sa valeur est définie. Sinon, il ne sera pas possible de construire une table contenant toutes ses valeurs, car il ne peut y avoir de table avec un nombre infini de lignes.

Exemple :

employeesCount ‘Nombre d'employés avec un salaire > N’ (Département d, NUMERIC[10,2] N) = 
    GROUPE SOMME salaire(Employé e) SI département(e) = d ET salaire(e) > N;


Cette fonction est définie pour une infinité de valeurs du nombre N (par exemple, toute valeur négative convient). Par conséquent, il est impossible d'appliquer MATERIALIZED. Ainsi, c'est une contrainte logique et non technique (c'est-à-dire que ce n'est pas parce que nous n'avons pas pu le réaliser). En dehors de cela, aucune restriction. Il est possible d'utiliser des regroupements, des tris, AND et OR, PARTITION, des récursions, etc.

Par exemple, dans la tâche 2.2 de l'article précédent, il est possible d'appliquer MATERIALIZED sur les deux fonctions :

acheté 'Achat' (Client c, Produit p, ENTIER y) = 
    SOMME DU GROUPE sum(Détail d) SI 
        client(commande(d)) = c ET 
        produit(d) = p ET 
        extraireAnnée(date(commande(d))) = y MATÉRIALISÉ;
évaluation 'Évaluation' (Client c, Produit p, ENTIER y) = 
    SOMME DE PARTITION 1 ORDRE DESC acheté(c, p, y), p PAR c, y MATÉRIALISÉ;
SÉLECTIONNER contactNom(Client c), nom(Produit p) OÙ évaluation(c, p, 1997) < 3;


Le système créera lui-même une table avec des clés de type Client, Produit et INTEGER, ajoutera deux champs et mettra à jour leurs valeurs lors de tout changement. Lors des appels futurs à ces fonctions, aucun calcul ne sera effectué, mais les valeurs seront lues à partir des champs correspondants.

À l'aide de ce mécanisme, il est possible, par exemple, de se débarrasser des récursions (CTE) dans les requêtes. En particulier, considérons les groupes qui forment un arbre à l'aide de la relation enfant/parent (chaque groupe a un lien vers son parent) :

parent = DATA Group (Groupe);


Dans une base de données fonctionnelle, la logique des récursions peut être définie comme suit :

niveau (Groupe enfant, Groupe parent) = RÉCURSION 1l SI enfant EST Groupe ET parent == enfant
                                                             ÉTAPE 2l SI parent == parent($parent);
estParent (Groupe enfant, Groupe parent) = VRAI SI niveau(enfant, parent) MATÉRIALISÉ;


Puisque la fonction isParent est marquée MATERIALIZED, une table avec deux clés (groupes) sera créée, dans laquelle le champ isParent sera vrai uniquement si la première clé est un descendant de la seconde. Le nombre d'enregistrements dans cette table sera égal au nombre de groupes multiplié par la profondeur moyenne de l'arbre. Si, par exemple, il est nécessaire de calculer le nombre de descendants d'un groupe spécifique, cette fonction peut être utilisée :

childrenCount (Groupe g) = SOMME GROUPE 1 SI isParent(Groupe enfant, g);


Il n'y aura pas de CTE dans la requête SQL. À la place, il y aura simplement un GROUP BY.

Grâce à ce mécanisme, il est également possible de procéder facilement à la dénormalisation de la base de données si nécessaire :

CLASS Commande 'Commande';
date 'Date' = DONNÉES DATE (Commande);

CLASS OrderDetail 'Détail de la commande';
order 'Commande' = DATA Order (OrderDetail);
date 'Date' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;

Lorsqu'il est question de la fonction date pour une ligne de commande, il y aura une lecture depuis la table des lignes de commandes pour le champ qui a un index. Lorsque la date de la commande change, le système recalculera automatiquement la date dénormalisée dans la ligne.

Avantages

À quoi sert tout ce mécanisme ? Dans les SGBD classiques, sans réécriture des requêtes, le développeur ou le DBA peuvent simplement modifier les index, définir des statistiques et suggérer au planificateur de requêtes comment les exécuter (et les HINTs ne sont disponibles que dans les SGBD commerciaux). Peu importe leurs efforts, ils ne pourront pas exécuter la première requête de l'article en O (nombre de départements) sans modifier les requêtes et ajouter des triggers. Dans le schéma proposé, au stade de développement, on peut ne pas penser à la structure de stockage des données et aux agrégations à utiliser. Tout cela peut être modifié à la volée directement en exploitation.

Dans la pratique, cela se présente comme suit. Certaines personnes développent directement la logique en fonction de la tâche fixée. Elles ne maîtrisent ni les algorithmes et leur complexité, ni les plans d'exécution, ni les types de jointures, ni aucun autre aspect technique. Ces personnes sont plutôt des analystes commerciaux que des développeurs. Ensuite, tout cela passe en test ou en production. La journalisation des requêtes longues est activée. Lorsqu'une requête longue est détectée, la décision d'activer MATERIALIZED sur une certaine fonction intermédiaire est prise par d'autres personnes (plus techniques — en fait des DBA). Cela ralentit légèrement l'écriture (car une mise à jour d'un champ supplémentaire dans la transaction est nécessaire). Cependant, non seulement cette requête est considérablement accélérée, mais toutes les autres qui utilisent cette fonction le sont également. La décision sur la fonction à matérialiser est relativement simple. Deux paramètres principaux : le nombre de valeurs d'entrée possibles (c'est exactement le nombre d'enregistrements qui se trouvera dans la table correspondante) et la fréquence de son utilisation dans d'autres fonctions.

Analogues

Dans les SGBD commerciaux modernes, il existe des mécanismes similaires : MATERIALIZED VIEW avec FAST REFRESH (Oracle) et INDEXED VIEW (Microsoft SQL Server). Dans PostgreSQL, MATERIALIZED VIEW ne peut pas être mise à jour dans une transaction, mais seulement sur demande (avec des restrictions très strictes), donc nous ne le prenons pas en considération. Cependant, ils présentent plusieurs problèmes qui limitent considérablement leur utilisation.

Premièrement, vous ne pouvez activer la matérialisation que si vous avez déjà créé une vue ordinaire. Sinon, il vous faudra réécrire toutes les autres requêtes qui accèdent à la nouvelle vue créée afin d'utiliser cette matérialisation. Ou laisser les choses telles qu'elles sont, mais cela sera au minimum inefficace si certaines données déjà pré-calculées existent, et que beaucoup de requêtes ne les utilisent pas toujours, mais les recalculent.

Deuxièmement, il existe un grand nombre de restrictions :

Oracle

5.3.8.4 Restrictions générales sur le rafraîchissement rapide

La requête définissant la vue matérialisée est limitée comme suit :

• La vue matérialisée ne doit pas contenir de références à des expressions non répétitives telles que SYSDATE and ROWNUM.
• La vue matérialisée ne doit pas contenir de références à RAW or LONG RAW types de données.
• Elle ne peut pas contenir un SELECT sous-requête de liste.
• Elle ne peut pas contenir de fonctions analytiques (par exemple, RANK) dans la SELECT clause.
• Elle ne peut pas référencer une table sur laquelle un index XMLIndex est défini.
• Elle ne peut pas contenir un MODEL clause.
• Elle ne peut pas contenir un clause avec une sous-requête. Elle ne peut pas contenir de requêtes imbriquées qui aient
• ANY ALL, , ou[START WITH …] CONNECT BY NOT soient « vrais », mais.
• Elle ne peut pas contenir un [START WITH …] CONNECT BY clause.
• Il ne peut pas contenir plusieurs tables de détail à différents sites.
• ACTIVER COMMIT les vues matérialisées ne peuvent pas avoir de tables de détail distantes.
• Les vues matérialisées imbriquées doivent avoir une jointure ou un agrégat.
• Les vues de jointure matérialisées et les vues agrégées matérialisées avec un GROUPE PAR la clause ne peut pas sélectionner à partir d'une table organisée par index.

5.3.8.5 Restrictions sur le Rafraîchissement Rapide sur les Vues Matérialisées avec Uniquement des Jointures

Les requêtes définissant des vues matérialisées avec uniquement des jointures et sans agrégats ont les restrictions suivantes sur le rafraîchissement rapide :

• Toutes les restrictions de «Restrictions Générales sur le Rafraîchissement Rapide«.
• Elles ne peuvent pas avoir GROUPE PAR clauses ou agrégats.
• Les Rowids de toutes les tables dans la DE liste doivent apparaître dans la SELECT liste de la requête.
• Les journaux de vues matérialisées doivent exister avec les rowids pour toutes les tables de base dans le DE liste de la requête.
• Vous ne pouvez pas créer une vue matérialisée rafraîchissable rapidement à partir de plusieurs tables avec des jointures simples qui incluent une colonne de type objet dans la SELECT déclaration.

De plus, la méthode de rafraîchissement que vous choisissez ne sera pas optimalement efficace si :

• La requête définissant utilise une jointure externe qui se comporte comme une jointure interne. Si la requête définissant contient une telle jointure, envisagez de réécrire la requête définissant pour qu'elle contienne une jointure interne.
• Le SELECT la liste de la vue matérialisée contient des expressions sur des colonnes provenant de plusieurs tables.

5.3.8.6 Restrictions sur le Rafraîchissement Rapide sur les Vues Matérialisées avec Agrégats

Les requêtes définissant des vues matérialisées avec des agrégats ou des jointures ont les restrictions suivantes sur le rafraîchissement rapide :

• Toutes les restrictions de «Restrictions Générales sur le Rafraîchissement Rapide«.

Le rafraîchissement rapide est supporté pour les deux ACTIVER COMMIT and ACTIVER SUR DEMANDE vues matérialisées, cependant les restrictions suivantes s'appliquent :

• Toutes les tables dans la vue matérialisée doivent avoir des journaux de vues matérialisées, et les journaux de vues matérialisées doivent :
  • Contenir toutes les colonnes de la table référencée dans la vue matérialisée.
  • Spécifiez avec ROWID and Y COMPRIS NOUVEAUX VALEURS.
  • Spécifiez la SÉQUENCE clause si la table est censée avoir un mélange d'inserts/chargements directs, de suppressions et de mises à jour.

• Seuls SOMME, COUNT, AVG, ÉCART TYPE, VARIANCE, MIN and MAX sont supportés pour le rafraîchissement rapide.
• COUNT(*) doit être spécifié.
• Les fonctions agrégées doivent apparaître uniquement comme la partie la plus extérieure de l'expression. C'est-à-dire, des agrégats tels que AVG(AVG(x)) or AVG(x)+ AVG(x) ne sont pas autorisés.
• Pour chaque agrégat tel que AVG(expr), le correspondant COUNT(expr) doit être présent. Oracle recommande que SOMME(expr) soit spécifié.
• Si VARIANCE(expr) or ÉCART TYPE(expr) est spécifié, COUNT(expr) and SOMME(expr) doit être spécifié. Oracle recommande que SOMME(expr *expr) soit spécifié.
• Le SELECT la colonne dans la requête définissant ne peut pas être une expression complexe avec des colonnes provenant de plusieurs tables de base. Un possible contournement à cela est d'utiliser une vue matérialisée imbriquée.
• Le SELECT la liste doit contenir toutes GROUPE PAR les colonnes.
• La vue matérialisée n'est pas basée sur une ou plusieurs tables distantes.
• Si vous utilisez un CHAR type de données dans les colonnes filtrées d'un journal de vues matérialisées, les ensembles de caractères du site maître et de la vue matérialisée doivent être les mêmes.
• Si la vue matérialisée a l'une des éléments suivants, alors le rafraîchissement rapide est supporté uniquement sur des inserts DML conventionnels et des chargements directs.
  • Vues matérialisées avec MIN or MAX agrégats
  • Vues matérialisées qui ont SOMME(expr) mais pas de COUNT(expr)
  • Vues matérialisées sans COUNT(*)

  Une telle vue matérialisée est appelée une vue matérialisée insérable uniquement.

• Une vue matérialisée avec MAX or MIN est rafraîchissable rapidement après des suppressions ou des déclarations DML mixtes si elle n'a pas un OÙ clause.
  Le rafraîchissement rapide max/min après des suppressions ou des DML mixtes n'a pas le même comportement que le cas insérable uniquement. Il supprime et recompute les valeurs max/min pour les groupes affectés. Vous devez être conscient de son impact sur les performances.
• Les vues matérialisées avec des vues nommées ou des sous-requêtes dans la DE clause peuvent être rafraîchies rapidement à condition que les vues puissent être entièrement fusionnées. Pour des informations sur les vues qui seront fusionnées, voir Référence du Langage SQL d'Oracle Database.
• S'il n'y a pas de jointures externes, vous pouvez avoir des sélections et des jointures arbitraires dans le OÙ clause.
• Les vues agrégées matérialisées avec des jointures externes sont rafraîchissables rapidement après un DML conventionnel et des chargements directs, à condition que seule la table externe ait été modifiée. De plus, des contraintes uniques doivent exister sur les colonnes de jointure de la table de jointure interne. S'il y a des jointures externes, toutes les jointures doivent être connectées par ANDet doivent utiliser l'égalité (=) l'opérateur.
• Pour les vues matérialisées avec CUBE, ROLLUP, des ensembles de regroupement, ou leur concaténation, les restrictions suivantes s'appliquent :
  • Le SELECT la liste doit contenir un identifiant de regroupement qui peut être soit un GROUPING_ID fonction sur toutes les GROUPE PAR expressions ou GROUPING fonctions, une pour chaque GROUPE PAR expression. Par exemple, si la GROUPE PAR clause de la vue matérialisée est «GROUPE PAR CUBE(a, b)«, alors la SELECT liste doit contenir soit «GROUPING_ID(a, b)» ou «GROUPING(a) AND GROUPING(b)» pour que la vue matérialisée soit rafraîchissable rapidement.
  • GROUPE PAR ne doit pas aboutir à des regroupements par duplicata. Par exemple, «GROUP BY a, ROLLUP(a, b)» n'est pas rapidement rafraîchissable car elle aboutit à des regroupements par duplicata «(a), (a, b), ET (a)«.

5.3.8.7 Restrictions sur le Rafraîchissement Rapide des Vues Matérialisées avec UNION ALL

Les vues matérialisées avec l'opérateur UNION , ou supportent l'option REFRESH FAST si les conditions suivantes sont respectées :

• La requête définissant doit avoir l'opérateur au niveau supérieur. UNION , ou l'opérateur ne peut pas être intégré dans une sous-requête, excepté dans une exception : le

  Le UNION , ou peut être dans une sous-requête dans la UNION , ou clause à condition que la requête définissant soit de la forme DE SELECT * FROM (vue ou sous-requête avec ) comme dans l'exemple suivant : UNION , ouCREATE 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 = 'Jones');CREATE MATERIALIZED VIEW unionall_inside_view_mv REFRESH FAST ON DEMAND AS SELECT * FROM view_with_unionall;

  Notez que la vue
  

  view_with_unionall satisfait les exigences pour un rafraîchissement rapide. Chaque bloc de requête dans la

• requête doit satisfaire aux exigences d'une vue matérialisée rapidement rafraîchissable avec des agrégats ou d'une vue matérialisée rapidement rafraîchissable avec des jointures. UNION , ou Les journaux de vue matérialisée appropriés doivent être créés sur les tables comme requis pour le type correspondant de vue matérialisée rapidement rafraîchissable.

  Notez que la base de données Oracle permet également le cas particulier d'une vue matérialisée avec jointures uniquement, à condition que la
  colonne ait été incluse dans la ROWID liste et dans le journal de la vue matérialisée. Cela est montré dans la requête définissant la vue. SELECT la liste de chaque requête doit inclure un satisfait les exigences pour un rafraîchissement rapide..

• Le SELECT marqueur, et la UNION , ou colonne doit avoir une valeur numérique ou de chaîne constante distincte dans chaque UNION , ou branche. De plus, la colonne de marqueur doit apparaître dans la même position ordinale dans la UNION , ou liste de chaque bloc de requête. Voir « SELECT UNION ALL Marker and Query Rewrite» pour plus d'informations concernantles marqueurs. UNION , ou Certaines fonctionnalités, telles que les jointures externes, les requêtes de vues matérialisées agrégées en mode insertion uniquement et les tables distantes ne sont pas prises en charge pour les vues matérialisées avec
• . Notez cependant que les vues matérialisées utilisées dans la réplication, qui ne contiennent ni jointures ni agrégats, peuvent être rafraîchies rapidement lorsque UNION , ouou des tables distantes sont utilisées. UNION , ou Le paramètre d'initialisation de compatibilité doit être réglé sur 9.2.0 ou plus pour créer une vue matérialisée rafraîchissable rapidement avec
• Le paramètre d'initialisation de compatibilité doit être défini sur 9.2.0 ou une version supérieure pour créer une vue matérialisée avec mise à jour rapide de UNION , ou.

Je ne veux pas blesser les fans d'Oracle, mais à en juger par leur liste de limitations, on a l'impression que ce mécanisme n'a pas été conçu de manière générale, en utilisant un modèle, mais par des milliers d'Indiens à qui on a donné la liberté d'écrire leur propre branche, avec chacun qui a fait ce qu'il a pu. Utiliser ce mécanisme pour de la logique réelle, c'est comme marcher sur un champ de mines. À tout moment, on peut déclencher une mine en tombant sur l'une des limitations non évidentes. Comment cela fonctionne, c'est une autre question, mais cela dépasse le cadre de cet article.

Microsoft SQL Server

Exigences supplémentaires

En plus des options SET et des exigences de fonction déterministe, les exigences suivantes doivent être satisfaites :

• L'utilisateur qui exécute CREATE INDEX doit être le propriétaire de la vue.
• Lorsque vous créez l'index, l’ IGNORE_DUP_KEY l'option doit être définie sur OFF (paramètre par défaut).
• Les tables doivent être référencées par des noms en deux parties, schéma.nom_de_table dans la définition de la vue.
• Les fonctions définies par l'utilisateur référencées dans la vue doivent être créées en utilisant l'option WITH SCHEMABINDING Tout fonction définie par l'utilisateur référencée dans la vue doit être référencée par des noms en deux parties,
• <schéma> <fonction>.La propriété d'accès aux données d'une fonction définie par l'utilisateur doit être.
• NO SQL , et la propriété d'accès externe doit êtreNON Les fonctions de runtime commun (CLR) peuvent apparaître dans la liste de sélection de la vue, mais ne peuvent pas faire partie de la définition de la clé d'index cluster. Les fonctions CLR ne peuvent pas apparaître dans la clause WHERE de la vue ou dans la clause ON d'une opération JOIN dans la vue..
• Les fonctions CLR et les méthodes des types définis par l'utilisateur CLR utilisés dans la définition de la vue doivent avoir les propriétés définies comme indiqué dans le tableau suivant.
• Remarque

  Propriété
  DÉTERMINISTIQUE = VRAI

  Doit être déclaré explicitement comme un attribut de la méthode Microsoft .NET Framework.
  PRÉCIS = VRAI

  Doit être déclaré explicitement comme un attribut de la méthode .NET Framework.
  ACCÈS AUX DONNÉES = AUCUN SQL

  Déterminé en définissant l'attribut DataAccess sur DataAccessKind.None et l'attribut SystemDataAccess sur SystemDataAccessKind.None.
  ACCÈS EXTERNE = AUCUN

  Cette propriété par défaut est NON pour les routines CLR.
  La vue doit être créée en utilisant le

• La vue doit faire uniquement référence aux tables de base qui se trouvent dans la même base de données que la vue. La vue ne peut pas référencer d'autres vues. WITH SCHEMABINDING Tout fonction définie par l'utilisateur référencée dans la vue doit être référencée par des noms en deux parties,
• La déclaration SELECT dans la définition de la vue ne doit pas contenir les éléments suivants de Transact-SQL :
• Fonctions ROWSET (

  COUNT
  OPENDATASOURCEOPENQUERY, OPENROWSET, , ETOPENXML JOINTS EXTÉRIEURS ()
  GAUCHE DROITTable dérivée (définie en spécifiant une, déclaration dans la[START WITH …] CONNECT BY FULL)

  clause) SELECT Auto-joints DE Spécifiant des colonnes en utilisant
  SELECT *
  SELECT <nom_de_table>.* STDEV or STDEVP

  DISTINCT
VAR, VARP, Expression de table commune (CTE), ntext[START WITH …] CONNECT BY AVG
  XML

  float1, text, filestream, image, colonnes[START WITH …] CONNECT BY Sous-requête CLAUSE OVER, qui inclut des fonctions de fenêtre de classement ou d'agrégation
  Prédicats de recherche en texte intégral (
  CONTIENT FREETEXT

  fonction qui référence une expression nullableFonction d'agrégation définie par l'utilisateur CLR, TOP)
  SOMME ENSEMBLES DE GROUPAGE
  ORDER BY

  opérateurs
  EXCEPT
CUBE, ROLLUP[START WITH …] CONNECT BY ÉCHANTILLONNER Variables de table

  MIN, MAX
UNION, OUTER APPLY[START WITH …] CONNECT BY INTERSECT Variables de table
  PIVOT

  UNPIVOT
  Ensembles de colonnes éparses or CROSS APPLY
Fonctions de table valorisées en ligne (TVF) ou multi-énoncé (MSTVF), CHECKSUM_AGG

  1 La vue indexée peut contenir
  colonnes ; cependant, de telles colonnes ne peuvent pas être incluses dans la clé d'index cluster.
  OFFSET

  GROUPE PAR

  est présent, la définition de la VUE doit contenir float COUNT_BIG(*)

• Si et ne doit pas contenir . Ces restrictions ne s'appliquent qu'à la définition de la vue indexée. Une requête peut utiliser une vue indexée dans son plan d'exécution même si elle ne respecte pas ces restrictions. clause avec une sous-requête.Si la définition de la vue contient une et ne doit pas contenir clause, la clé de l'index cluster unique ne peut faire référence qu'aux colonnes spécifiées dans le et ne doit pas contenir restrictions.
• Si la définition de la vue contient un et ne doit pas contenir clause, la clé de l'index clusterisé unique ne peut référencer que les colonnes spécifiées dans le et ne doit pas contenir clause.

Il est clair que les Indiens n'ont pas été attirés, car ils ont décidé de suivre le schéma "nous ferons peu, mais bien". Cela signifie qu'ils ont plus de mines sur le terrain, mais leur emplacement est plus transparent. Ce qui est le plus décevant, c'est cette restriction :

La déclaration SELECT dans la définition de la vue ne doit pas contenir les éléments suivants de Transact-SQL :

Dans notre terminologie, cela signifie qu'une fonction ne peut pas faire appel à une autre fonction matérialisée. Cela met à mal toute l'idéologie.
Cette restriction (et plus loin dans le texte) réduit considérablement les possibilités d'utilisation :

Fonctions ROWSET (

COUNT
OPENDATASOURCEOPENQUERY, OPENROWSET, , ETOPENXML JOINTS EXTÉRIEURS ()
GAUCHE DROITTable dérivée (définie en spécifiant une, déclaration dans la[START WITH …] CONNECT BY FULL)

clause) SELECT Auto-joints DE Spécifiant des colonnes en utilisant
SELECT *
SELECT <nom_de_table>.* STDEV or STDEVP

DISTINCT
VAR, VARP, Expression de table commune (CTE), ntext[START WITH …] CONNECT BY AVG
XML

float1, text, filestream, image, colonnes[START WITH …] CONNECT BY Sous-requête CLAUSE OVER, qui inclut des fonctions de fenêtre de classement ou d'agrégation
Prédicats de recherche en texte intégral (
CONTIENT FREETEXT

fonction qui référence une expression nullableFonction d'agrégation définie par l'utilisateur CLR, TOP)
SOMME ENSEMBLES DE GROUPAGE
ORDER BY

opérateurs
EXCEPT
CUBE, ROLLUP[START WITH …] CONNECT BY ÉCHANTILLONNER Variables de table

MIN, MAX
UNION, OUTER APPLY[START WITH …] CONNECT BY INTERSECT Variables de table
PIVOT

UNPIVOT
Ensembles de colonnes éparses or CROSS APPLY
Fonctions de table valorisées en ligne (TVF) ou multi-énoncé (MSTVF), CHECKSUM_AGG

1 La vue indexée peut contenir
colonnes ; cependant, de telles colonnes ne peuvent pas être incluses dans la clé d'index cluster.
OFFSET

GROUPE PAR

Les OUTER JOINS, UNION, ORDER BY, et autres sont interdits. Il aurait peut-être été plus simple d'indiquer ce qui peut être utilisé, plutôt que ce qui ne peut pas. La liste aurait probablement été beaucoup plus courte.

En résumé : un vaste ensemble de restrictions dans chaque SGBD (je souligne commercial) vs aucune (à l'exception d'une logique, pas technique) dans la technologie LGPL. Cependant, il convient de noter que la mise en œuvre de ce mécanisme dans une logique relationnelle est un peu plus complexe que dans la logique fonctionnelle décrite.

Mise en œuvre

Comment cela fonctionne-t-il ? Comme "machine virtuelle", PostgreSQL est utilisé. À l'intérieur, il y a un algorithme complexe qui s'occupe de la construction des requêtes. Voici le code source. Et il n'y a pas simplement un grand nombre d'heuristiques avec une multitude de if. Donc, si vous avez quelques mois pour étudier, vous pouvez essayer de comprendre l'architecture.

Est-ce que cela fonctionne efficacement ? Assez efficacement. Malheureusement, il est difficile de le prouver. Je ne peux que dire que si l'on considère des milliers de requêtes dans de grandes applications, en moyenne elles sont plus efficaces que celles d'un bon développeur. Un excellent programmeur SQL peut écrire n'importe quelle requête de manière plus efficace, mais sur mille requêtes, il n'a tout simplement ni la motivation ni le temps de le faire. La seule chose que je peux apporter comme preuve d'efficacité est que plusieurs projets fonctionnent sur une plateforme basée sur ce SGBD systèmes ERP, dans lesquels il y a des milliers de fonctions MATERIALIZED différentes, avec des milliers d'utilisateurs et des bases de données de téraoctets contenant des centaines de millions d'enregistrements, fonctionnant sur un serveur à deux processeurs ordinaire. Cependant, quiconque le souhaite peut vérifier/réfuter l'efficacité en téléchargeant la plateforme et PostgreSQL, en activant la journalisation des requêtes SQL et en essayant de modifier la logique et les données.

Dans les articles suivants, je parlerai également de la manière d'imposer des restrictions sur les fonctions, de la gestion des sessions de modifications et bien plus encore.

Source : habr.com