Principes fondamentaux des expressions de table, Partie 2 – Tables dérivées, considérations logiques

La définition de la table dérivée apparaît là où une table de base peut normalement apparaître, dans la clause FROM de la requête externe. Il peut s'agir d'une entrée pour un opérateur de table tel que JOIN, APPLY, PIVOT et UNPIVOT. Lorsqu'elle est utilisée comme entrée correcte d'un opérateur APPLY, la partie de la table dérivée est autorisée à avoir des corrélations avec les colonnes d'une table externe (plus d'informations à ce sujet dans un futur article dédié de la série). Sinon, l'expression de table doit être autonome.

L'instruction externe peut avoir tous les éléments de requête habituels. Dans le cas d'une instruction SELECT :WHERE, GROUP BY, HAVING, ORDER BY et, comme mentionné, les opérateurs de table dans la clause FROM.

Voici un exemple de requête simple sur une table dérivée représentant des clients américains :

SELECT custid, companynameFROM ( SELECT custid, companyname FROM Sales.Customers WHERE country =N'USA' ) AS UC ;

Cette requête génère la sortie suivante :

nom de l'entreprise client------- ---------------32 Client YSIQX36 Client LVJSO43 Client UISOJ45 Client QXPPT48 Client DVFMB55 Client KZQZT65 Client NYUHS71 Client LCOUJ75 Client XOJYP77 Client LCYBZ78 Client NLTYP82 Client EYHKM89 Client YBQTI

Il existe trois parties principales à identifier dans une instruction impliquant une définition de table dérivée :

1. L'expression de table (la requête interne)
2. Le nom de la table dérivée, ou plus précisément, ce qui, dans la théorie relationnelle, est considéré comme une variable de plage
3. La déclaration externe

L'expression de table est censée représenter une table et, en tant que telle, doit satisfaire certaines exigences qu'une requête normale n'a pas nécessairement besoin de satisfaire. Je fournirai les détails sous peu dans la section "Une expression de table est une table".

Quant au nom de la table dérivée cible ; une hypothèse courante parmi les développeurs T-SQL est qu'il s'agit simplement d'un nom ou d'un alias que vous attribuez à la table cible. De même, considérez la requête suivante :

SELECT custid, companynameFROM Sales.Customers AS CWHERE country =N'USA';

Ici également, l'hypothèse courante est que AS C est simplement un moyen de renommer, ou d'alias, la table Customers aux fins de cette requête, en commençant par l'étape de traitement de la requête logique où le nom est attribué et au-delà. Cependant, du point de vue de la théorie relationnelle, il y a un sens plus profond à ce que représente C. C est ce qu'on appelle une variable de plage. C est une variable de relation dérivée qui s'étend sur les tuples de la variable de relation d'entrée Customers. Dans l'exemple ci-dessus, C parcourt les tuples dans Customers et évalue le prédicat country =N'USA'. Les tuples pour lesquels le prédicat est évalué comme vrai font partie de la relation de résultat C.

Une expression de table est une table

Avec le contexte que j'ai fourni jusqu'à présent, ce que je vais vous expliquer ensuite ne devrait pas vous surprendre. La partie d'une définition de table dérivée est une table . C'est le cas même si c'est exprimé sous forme de requête. Vous souvenez-vous de la propriété de fermeture de l'algèbre relationnelle ? Il en va de même pour le reste des expressions de table nommées susmentionnées (CTE, vues et TVF en ligne). Comme vous l'avez déjà appris, la table de SQL est le pendant de la relation de la théorie relationnelle , bien qu'il ne s'agisse pas d'une contrepartie parfaite. Ainsi, une expression de table doit satisfaire certaines exigences pour s'assurer que le résultat est une table, celles qu'une requête qui n'est pas utilisée comme expression de table n'a pas nécessairement à respecter. Voici trois exigences spécifiques :

• Toutes les colonnes de l'expression de table doivent avoir des noms
• Tous les noms de colonne de l'expression de table doivent être uniques
• Les lignes de l'expression de table n'ont pas d'ordre

Décomposons ces exigences une par une, en discutant de la pertinence à la fois de la théorie relationnelle et de SQL.

Toutes les colonnes doivent avoir des noms

Rappelez-vous qu'une relation a un titre et un corps. L'en-tête d'une relation est un ensemble d'attributs (colonnes en SQL). Un attribut a un nom et un nom de type, et est identifié par son nom. Une requête qui n'est pas utilisée comme expression de table ne doit pas nécessairement attribuer des noms à toutes les colonnes cibles. Considérez la requête suivante comme exemple :

SELECT empid, prénom, nom, CONCAT_WS(N'/', pays, région, ville)FROM HR.Employees ;

Cette requête génère la sortie suivante :

empid firstname lastname (Aucun nom de colonne)------ ---------- ---------- ------------- ----1 Sara Davis États-Unis/WA/Seattle2 Don Funk États-Unis/WA/Tacoma3 Judy Lew États-Unis/WA/Kirkland4 Yael Peled États-Unis/WA/Redmond5 Sven Mortensen Royaume-Uni/Londres6 Paul Suurs Royaume-Uni/Londres7 Russell King Royaume-Uni/Londres8 Maria Cameron États-Unis/WA/Seattle9 Patricia Doyle Royaume-Uni/Londres

La sortie de la requête comporte une colonne anonyme résultant de la concaténation des attributs d'emplacement à l'aide de la fonction CONCAT_WS. (Au fait, cette fonction a été ajoutée dans SQL Server 2017, donc si vous exécutez le code dans une version antérieure, n'hésitez pas à remplacer ce calcul par un calcul alternatif de votre choix.) Cette requête, par conséquent, ne retourner une table, pour ne pas parler d'une relation. Par conséquent, il n'est pas valide d'utiliser une telle requête comme partie expression de table/requête interne d'une définition de table dérivée.

Essayez-le :

SELECT *FROM ( SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city) FROM HR.Employees ) AS D ;

Vous obtenez l'erreur suivante :

En aparté, remarquez quelque chose d'intéressant dans le message d'erreur ? Il se plaint de la colonne 4, soulignant la différence entre les colonnes en SQL et les attributs en théorie relationnelle.

La solution est, bien sûr, de s'assurer que vous attribuez explicitement des noms aux colonnes qui résultent des calculs. T-SQL prend en charge un certain nombre de techniques de nommage de colonnes. Je vais en citer deux.

Vous pouvez utiliser une technique de dénomination en ligne dans laquelle vous attribuez le nom de la colonne cible après le calcul et une clause AS facultative, comme dans < expression > [ AS ] < column name > , comme ceci :

SELECT empid, firstname, lastname, custlocationFROM ( SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city) AS custlocation FROM HR.Employees ) AS D ;

Cette requête génère la sortie suivante :

empid firstname lastname custlocation------ ---------- ---------- ----------------1 Sara Davis États-Unis/WA/Seattle2 Don Funk États-Unis/WA/Tacoma3 Judy Lew États-Unis/WA/Kirkland4 Yael Peled États-Unis/WA/Redmond5 Sven Mortensen Royaume-Uni/Londres6 Paul Suurs Royaume-Uni/Londres7 Russell King Royaume-Uni/Londres8 Maria Cameron États-Unis/WA/Seattle9 Patricia Doyle Royaume-Uni/Londres

En utilisant cette technique, il est très facile lors de la révision du code de dire quel nom de colonne cible est attribué à quelle expression. De plus, vous n'avez qu'à nommer les colonnes qui n'ont pas encore de nom autrement.

Vous pouvez également utiliser une technique de dénomination de colonne plus externe dans laquelle vous spécifiez les noms de colonne cible entre parenthèses juste après le nom de la table dérivée, comme ceci :

SELECT empid, firstname, lastname, custlocationFROM ( SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city) FROM HR.Employees ) AS D(empid, firstname, lastname, custlocation); 

 Avec cette technique cependant, vous devez répertorier les noms de toutes les colonnes, y compris celles qui ont déjà des noms. L'attribution des noms de colonne cible se fait par position, de gauche à droite, c'est-à-dire que le premier nom de colonne cible représente la première expression dans la liste SELECT de la requête interne ; le nom de la deuxième colonne cible représente la deuxième expression ; etc. 
 

 Notez qu'en cas d'incohérence entre les noms de colonne interne et externe, par exemple en raison d'un bogue dans le code, la portée des noms internes est la requête interne ou, plus précisément, la variable de plage interne (ici implicitement HR.Employees AS Employees) - et la portée des noms externes est la variable de plage externe (D dans notre cas). La portée des noms de colonne est un peu plus impliquée dans le traitement logique des requêtes, mais c'est un élément pour des discussions ultérieures.
 

 Le potentiel de bogues avec la syntaxe de nommage externe est mieux expliqué avec un exemple. 
 

 Examinez le résultat de la requête précédente, avec l'ensemble complet d'employés de la table HR.Employees. Ensuite, considérez la requête suivante, et avant de l'exécuter, essayez de déterminer quels employés vous vous attendez à voir dans le résultat :
 
SELECT empid, firstname, lastname, custlocationFROM ( SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city) FROM HR.Employees WHERE lastname LIKE N'D%' ) AS D(empid, nom, prénom, custlocation)WHERE prénom LIKE N'D%';
 

 Si vous vous attendez à ce que la requête renvoie un ensemble vide pour les exemples de données donnés, puisqu'il n'y a actuellement aucun employé dont le nom et le prénom commencent par la lettre D, il vous manque le bogue dans le code. 
 

 Exécutez maintenant la requête et examinez le résultat réel :
 
empid firstname lastname custlocation------ ---------- --------- ---------------1 Davis Sara États-Unis/WA/Seattle9 Doyle Patricia Royaume-Uni/Londres
 

 Que s'est-il passé ?
 

 La requête interne spécifie firstname comme deuxième colonne et lastname comme troisième colonne dans la liste SELECT. Le code qui attribue les noms de colonne cible de la table dérivée dans la requête externe spécifie le nom de famille en deuxième et le prénom en troisième. Les noms de code firstname as lastname et lastname as firstname dans la variable de plage D. En fait, vous ne filtrez que les employés dont le nom commence par la lettre D. Vous ne filtrez pas les employés dont le nom et le prénom commencent par avec la lettre D.
 

 La syntaxe d'alias en ligne n'est pas sujette à de tels bogues. D'une part, vous n'utilisez normalement pas d'alias pour une colonne qui a déjà un nom qui vous convient. Deuxièmement, même si vous souhaitez affecter un alias différent à une colonne qui a déjà un nom, il est peu probable qu'avec la syntaxe  AS  vous affectiez le mauvais alias. Pensez-y; quelle est la probabilité que vous écriviez comme ceci :
 
SELECT empid, firstname, lastname, custlocationFROM ( SELECT empid AS empid, firstname AS lastname, lastname AS firstname, CONCAT_WS(N'/', country, region, city) AS custlocation FROM HR.Employees WHERE lastname LIKE N'D %' ) AS DWHERE prénom LIKE N'D%';
 

 Évidemment, peu probable.
 
Tous les noms de colonne doivent être uniques
 

 Revenons au fait que l'en-tête d'une relation est un ensemble d'attributs, et étant donné qu'un attribut est identifié par son nom, les noms d'attributs doivent être uniques pour une même relation. Dans une requête donnée, vous pouvez toujours faire référence à un attribut en utilisant un nom en deux parties avec le nom de la variable de plage comme qualificatif, comme dans .. Lorsque le nom de la colonne sans le qualificatif est sans ambiguïté, vous pouvez omettre le préfixe du nom de la variable de plage. Ce qu'il est important de retenir, cependant, c'est ce que j'ai dit plus tôt à propos de la portée des noms de colonne. Dans le code qui implique une expression de table nommée, avec à la fois une requête interne (l'expression de table) et une requête externe, la portée des noms de colonne dans la requête interne correspond aux variables de plage internes et la portée des noms de colonne dans la requête externe. query sont les variables de la plage extérieure. Si la requête interne implique plusieurs tables source avec le même nom de colonne, vous pouvez toujours faire référence à ces colonnes de manière non ambiguë en ajoutant le nom de la variable de plage comme préfixe. Si vous n'affectez pas explicitement un nom de variable de plage, vous en obtenez un implicitement, comme si vous utilisiez  AS .
 

 Considérez la requête autonome suivante comme exemple :
 
SELECT C.custid, O.custid, O.orderidFROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid;
 

 Cette requête n'échoue pas avec une erreur de nom de colonne en double car une colonne custid est en fait nommée C.custid et l'autre O.custid dans la portée de la requête actuelle. Cette requête génère la sortie suivante :
 
custid custid orderid----------- ----------- -----------1 1 106431 1 106921 1 107021 1 108351 1 109521 1 110112 2 103082 2 106252 2 107592 2 10926...
 

 Cependant, essayez d'utiliser cette requête comme expression de table dans la définition d'une table dérivée nommée CO, comme ceci :
 
SELECT *FROM ( SELECT C.custid, O.custid, O.orderid FROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid ) AS CO ;
 

 En ce qui concerne la requête externe, vous avez une variable de plage nommée CO, et la portée de tous les noms de colonne dans la requête externe est cette variable de plage. Les noms de toutes les colonnes d'une variable de plage donnée (rappelez-vous qu'une variable de plage est une variable de relation) doivent être uniques. Par conséquent, vous obtenez l'erreur suivante :
 Msg 8156, Niveau 16, État 1, Ligne 80
La colonne 'custid' a été spécifiée plusieurs fois pour 'CO'. 

 La solution consiste bien sûr à attribuer des noms de colonne différents aux deux colonnes custid en ce qui concerne la variable de plage CO, comme ceci :
 
SELECT *FROM ( SELECT C.custid AS custid, O.custid AS ordercustid, O.orderid FROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid ) AS CO; 

 Cette requête génère la sortie suivante :
 
custcustid ordercustid orderid----------- ----------- -----------1 1 106431 1 106921 1 107021 1 108351 1 109521 1 110112 2 103082 2 106252 2 107592 2 10926...
 

 Si vous suivez les bonnes pratiques, vous répertoriez explicitement les noms de colonne dans la liste SELECT de la requête la plus externe. Puisqu'il n'y a qu'une seule variable de plage impliquée, vous n'avez pas besoin d'utiliser le nom en deux parties pour les références de colonne externes. Si vous souhaitez utiliser le nom en deux parties, vous préfixez les noms de colonne avec le nom de variable de plage externe CO, comme ceci :
 
SELECT CO.custcustid, CO.ordercustid, CO.orderidFROM ( SELECT C.custid AS custid, O.custid AS ordercustid, O.orderid FROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid ) AS CO;
 
Pas de commande
 

 Il y a beaucoup de choses que j'ai à dire sur les expressions de table nommées et l'ordre - assez pour un article à part entière - donc je consacrerai un futur article à ce sujet. Pourtant, je voulais aborder brièvement le sujet ici car il est si important. Rappelons que le corps d'une relation est un ensemble de tuples, et de même, le corps d'une table est un ensemble de lignes. Un ensemble n'a pas d'ordre. Pourtant, SQL permet à la requête la plus externe d'avoir une clause ORDER BY servant une signification d'ordre de présentation, comme le montre la requête suivante :
 
SELECT orderid, valFROM Sales.OrderValuesORDER BY val DESC ;
 

 Ce que vous devez comprendre, cependant, c'est que cette requête ne renvoie pas de relation en conséquence. Même du point de vue de SQL, la requête ne renvoie pas de table en conséquence, et donc elle ne l'est pas considérée comme une expression de table. Par conséquent, il n'est pas valide d'utiliser une telle requête comme partie d'expression de table d'une définition de table dérivée. 
 

 Essayez d'exécuter le code suivant :
 
SELECT orderid, valFROM ( SELECT orderid, val FROM Sales.OrderValues ​​ORDER BY val DESC ) AS D ;
 

 Vous obtenez l'erreur suivante :
 Msg 1033, niveau 15, état 1, ligne 124
La clause ORDER BY n'est pas valide dans les vues, les fonctions en ligne, les tables dérivées, les sous-requêtes et les expressions de table communes, sauf si TOP, OFFSET ou FOR XML est également spécifié. 

 J'aborderai le sauf si une partie du message d'erreur sous peu.
 

 Si vous voulez que la requête la plus externe renvoie un résultat ordonné, vous devez spécifier la clause ORDER BY dans la requête la plus externe, comme suit :
 
SELECT orderid, valFROM ( SELECT orderid, val FROM Sales.OrderValues ​​) AS DORDER BY val DESC ;
 

 Quant au sauf si une partie du message d'erreur ; T-SQL prend en charge le filtre TOP propriétaire ainsi que le filtre standard OFFSET-FETCH. Les deux filtres s'appuient sur une clause ORDER BY dans la même étendue de requête pour définir pour eux les premières lignes à filtrer. C'est malheureusement le résultat d'un piège dans la conception de ces fonctionnalités, qui ne sépare pas l'ordre de présentation de l'ordre des filtres. Quoi qu'il en soit, Microsoft avec son filtre TOP et la norme avec son filtre OFFSET-FETCH permettent de spécifier une clause ORDER BY dans la requête interne tant qu'elle spécifie également le filtre TOP ou OFFSET-FETCH, respectivement. Donc, cette requête est valide, par exemple :
 
SELECT orderid, valFROM ( SELECT TOP (3) orderid, val FROM Sales.OrderValues ​​ORDER BY val DESC ) AS D ;
 

 Lorsque j'ai exécuté cette requête sur mon système, elle a généré le résultat suivant :
 
id_commande-------- ---------10865 16387.5010981 15810.0011030 12615.05
 

 Ce qu'il est important de souligner cependant, c'est que la seule raison pour laquelle la clause ORDER BY est autorisée dans la requête interne est de prendre en charge le filtre TOP. C'est la seule garantie que vous obtenez en ce qui concerne la commande. Étant donné que la requête externe n'a pas non plus de clause ORDER BY, vous n'obtenez aucune garantie pour un ordre de présentation spécifique à partir de cette requête, quel que soit le comportement observé. C'est à la fois le cas dans T-SQL, ainsi que dans la norme. Voici une citation de la norme traitant de cette partie :
 "L'ordre des lignes de la table spécifiée par  n'est garanti que pour l' qui contient immédiatement la ." 

 Comme mentionné, il y a beaucoup plus à dire sur les expressions de table et l'ordre, ce que je ferai dans un prochain article. Je fournirai également des exemples démontrant comment l'absence de clause ORDER BY dans la requête externe signifie que vous n'obtenez aucune garantie de classement de présentation.
 

 Ainsi, une expression de table, par exemple une requête interne dans une définition de table dérivée, est une table. De même, une table dérivée (au sens spécifique) est elle-même aussi une table. Ce n'est pas une table basse, mais c'est quand même une table. Il en va de même pour les CTE, les vues et les TVF en ligne. Ce ne sont pas des tables de base, plutôt des tables dérivées (au sens le plus général), mais ce sont néanmoins des tables.
 
Défauts de conception
 

 Les tables dérivées présentent deux défauts principaux dans leur conception. Les deux sont liés au fait que la table dérivée est définie dans la clause FROM de la requête externe.
 

 Un défaut de conception a à voir avec le fait que si vous devez interroger une table dérivée à partir d'une requête externe, et à son tour utiliser cette requête comme expression de table dans une autre définition de table dérivée, vous finissez par imbriquer ces requêtes de table dérivée. En informatique, l'imbrication explicite de code impliquant plusieurs niveaux d'imbrication a tendance à aboutir à un code complexe difficile à maintenir.
 

 Voici un exemple très basique le démontrant :
 
SELECT orderyear, numcustsFROM ( SELECT orderyear, COUNT(DISTINCT custid) AS numcusts FROM ( SELECT YEAR(orderdate) AS orderyear, custid FROM Sales.Orders ) AS D1 GROUP BY orderyear ) AS D2WHERE numcusts> 70 ;
 

 Ce code renvoie les années de commande et le nombre de clients qui ont passé des commandes au cours de chaque année, uniquement pour les années où le nombre de clients qui ont passé des commandes était supérieur à 70.
 

 La principale motivation pour utiliser des expressions de table ici est de pouvoir se référer plusieurs fois à un alias de colonne. La requête la plus interne utilisée comme expression de table pour la table dérivée D1 interroge la table Sales.Orders et attribue le nom de colonne orderyear à l'expression YEAR(orderdate) et renvoie également la colonne custid. La requête sur D1 regroupe les lignes de D1 par orderyear et renvoie orderyear ainsi que le nombre distinct de clients qui ont passé des commandes au cours de l'année en question, alias numcusts. Le code définit une table dérivée appelée D2 basée sur cette requête. La requête la plus à l'extérieur des requêtes D2 et filtre uniquement les années où le nombre de clients ayant passé des commandes était supérieur à 70.
 

 Une tentative de révision de ce code ou de dépannage en cas de problème est délicate en raison des multiples niveaux d'imbrication. Au lieu d'examiner le code de la manière la plus naturelle de haut en bas, vous vous retrouvez à devoir l'analyser en commençant par l'unité la plus interne et en allant progressivement vers l'extérieur, car c'est plus pratique.
 

 L'intérêt de l'utilisation de tables dérivées dans cet exemple était de simplifier le code en évitant d'avoir à répéter des expressions. Mais je ne suis pas sûr que cette solution atteigne cet objectif. Dans ce cas, vous feriez probablement mieux de répéter certaines expressions, en évitant d'avoir à utiliser des tables dérivées, comme ceci :
 
SELECT YEAR(orderdate) AS orderyear, COUNT(DISTINCT custid) AS numcustsFROM Sales.OrdersGROUP BY YEAR(orderdate)HAVING COUNT(DISTINCT custid)> 70 ;
 

 Gardez à l'esprit que je montre ici un exemple très simple à des fins d'illustration. Imaginez un code de production avec plus de niveaux d'imbrication, et avec un code plus long et plus élaboré, et vous pouvez voir comment il devient beaucoup plus compliqué à maintenir.
 

 Un autre défaut dans la conception des tables dérivées concerne les cas où vous devez interagir avec plusieurs instances de la même table dérivée. Considérez la requête suivante comme exemple :
 
SELECT CUR.orderyear, CUR.numorders, CUR.numorders - PRV.numorders AS diffFROM ( SELECT YEAR(orderdate) AS orderyear, COUNT(*) AS numorders FROM Sales.Orders GROUP BY YEAR(orderdate) ) AS CUR LEFT OUTER JOIN ( SELECT YEAR(orderdate) AS orderyear, COUNT(*) AS numorders FROM Sales.Orders GROUP BY YEAR(orderdate) ) AS PRV ON CUR.orderyear =PRV.orderyear + 1;
 

 Ce code calcule le nombre de commandes traitées chaque année, ainsi que la différence par rapport à l'année précédente. Ignorez le fait qu'il existe des moyens plus simples d'accomplir la même tâche avec les fonctions de fenêtre - j'utilise ce code pour illustrer un certain point, donc la tâche elle-même et les différentes façons de la résoudre ne sont pas significatives. 
 

 Une jointure est un opérateur de table qui traite ses deux entrées comme un ensemble, ce qui signifie qu'il n'y a pas d'ordre entre elles. Ils sont appelés les entrées gauche et droite afin que vous puissiez marquer l'un d'eux (ou les deux) comme une table préservée dans une jointure externe, mais il n'y a toujours pas de premier et de deuxième parmi eux. Vous êtes autorisé à utiliser des tables dérivées comme entrées de jointure, mais le nom de la variable de plage que vous affectez à l'entrée de gauche n'est pas accessible dans la définition de l'entrée de droite. C'est parce que les deux sont conceptuellement définis dans la même étape logique, comme s'ils étaient au même moment. Par conséquent, lors de la jointure de tables dérivées, vous ne pouvez pas définir deux variables de plage basées sur une expression de table. Malheureusement, vous devez répéter le code, en définissant deux variables de plage basées sur deux copies identiques du code. Cela complique bien sûr la maintenabilité du code et augmente la probabilité de bogues. Chaque modification que vous apportez à une expression de table doit également être appliquée à l'autre.
 

 Comme je l'expliquerai dans un prochain article, les CTE, dans leur conception, n'encourent pas ces deux défauts que les tables dérivées encourent.
 
Constructeur de valeur de table
 

 Un constructeur de valeur de table vous permet de construire une valeur de table basée sur des expressions scalaires autonomes. Vous pouvez ensuite utiliser une telle table dans une requête externe, tout comme vous utilisez une table dérivée basée sur une requête interne. Dans un prochain article, je discuterai des tables dérivées latérales et les corrélations en détail, et je montrerai des formes plus sophistiquées de constructeurs de valeurs de table. Dans cet article, cependant, je vais me concentrer sur une forme simple basée uniquement sur des expressions scalaires autonomes.
 

 The general syntax for a query against a table value constructor is as follows:
 SELECT 
FROM (