Différences entre Entity SQL et Transact-SQL

Cet article décrit les différences entre Entity SQL et Transact-SQL.

Prise en charge de l’héritage et des relations

Entity SQL fonctionne directement avec des schémas d’entité conceptuelles et prend en charge les fonctionnalités de modèle conceptuel telles que l’héritage et les relations.

Lorsque vous utilisez l’héritage, il est souvent utile de sélectionner des instances d’un sous-type à partir d’une collection d’instances de supertype. L’opérateur oftype dans Entity SQL (similaire à oftype en séquences C#) fournit cette fonctionnalité.

Prise en charge des collections

Entity SQL traite les collections en tant qu’entités de première classe. Par exemple:

Les expressions de collection sont valides dans une clause from.
Les sous-requêtes in et exists ont été généralisées pour autoriser toute collection.

Une sous-requête est un type de collection. e1 in e2 et exists(e) sont les constructions Entity SQL pour effectuer ces opérations.
Les opérations telles que union, intersect et except fonctionnent désormais sur des collections.
Les jointures s’appliquent aux collections.

Prise en charge des expressions

Transact-SQL a des sous-requêtes (tables) et des expressions (lignes et colonnes).

Pour prendre en charge les collections et les collections imbriquées, Entity SQL rend tout une expression. Entity SQL est plus composable que Transact-SQL. Chaque expression peut être utilisée n’importe où. Les expressions de requête entraînent toujours des collections des types projetés et peuvent être utilisées n’importe où une expression de collection est autorisée. Pour plus d’informations sur les expressions Transact-SQL qui ne sont pas prises en charge dans Entity SQL, consultez Expressions non prises en charge.

Voici toutes les requêtes Entity SQL valides :

1+2 *3  
"abc"  
row(1 as a, 2 as b)  
{ 1, 3, 5}
e1 union all e2  
set(e1)

Traitement uniforme des sous-requêtes

Compte tenu de l’accent mis sur les tables, Transact-SQL effectue une interprétation contextuelle des sous-requêtes. Par exemple, une sous-requête dans la from clause est considérée comme un multiset (table). Mais la même sous-requête utilisée dans la select clause est considérée comme une sous-requête scalaire. De même, une sous-requête utilisée à gauche d’un in opérateur est considérée comme une sous-requête scalaire, tandis que le côté droit est censé être une sous-requête multiset.

Entity SQL élimine ces différences. Une expression a une interprétation uniforme qui ne dépend pas du contexte dans lequel elle est utilisée. Entity SQL considère que toutes les sous-requêtes sont des sous-requêtes multiset. Si une valeur scalaire est souhaitée à partir de la sous-requête, Entity SQL fournit l’opérateur anyelement qui opère sur une collection (dans ce cas, la sous-requête) et extrait une valeur singleton de la collection.

Éviter les contraintes implicites pour les sous-requêtes

Un effet secondaire connexe du traitement uniforme des sous-requêtes est une conversion implicite des sous-requêtes en valeurs scalaires. Plus précisément, dans Transact-SQL, un multiset de lignes (avec un seul champ) est implicitement converti en valeur scalaire dont le type de données est celui du champ.

Entity SQL ne prend pas en charge ce forçage implicite. Entity SQL fournit l’opérateur ANYELEMENT pour extraire une valeur singleton d’une collection et une select value clause pour éviter de créer un wrapper de lignes pendant une expression de requête.

Select Value : éviter le wrapper de ligne implicite

La clause select d’une sous-requête Transact-SQL crée implicitement un wrapper de lignes autour des éléments de la clause. Cela implique que nous ne pouvons pas créer de collections de scalaires ou d’objets. Transact-SQL autorise une coercition implicite entre un champ dans un rowtype et une valeur singleton du même type de données.

Entity SQL fournit la select value clause pour ignorer la construction de ligne implicite. Un seul élément peut être spécifié dans une select value clause. Lorsqu’une telle clause est utilisée, aucun wrapper de ligne n’est construit autour des éléments de la select clause, et une collection de la forme souhaitée peut être produite, par exemple select value a.

Entity SQL fournit également le constructeur de ligne pour construire des lignes arbitraires. select prend un ou plusieurs éléments dans la projection et génère un enregistrement de données avec des champs :

select a, b, c

Corrélation à gauche et effet d'aliasing

Dans Transact-SQL, les expressions d’une étendue donnée (une clause unique comme select ou from) ne peuvent pas référencer des expressions définies précédemment dans la même étendue. Certains dialectes de SQL (y compris Transact-SQL) prennent en charge des formes limitées de celles-ci dans la from clause.

Entity SQL généralise les corrélations gauches dans la from clause et les traite uniformément. Les expressions de la from clause peuvent référencer des définitions antérieures (définitions à gauche) dans la même clause sans avoir besoin de syntaxe supplémentaire.

Entity SQL impose également des restrictions supplémentaires sur les requêtes impliquant des clauses group by. Les expressions de la clause select et de la clause having de ces requêtes ne peuvent faire référence qu’aux clés group by via leurs alias. La construction suivante est valide dans Transact-SQL, mais pas dans Entity SQL :

SELECT t.x + t.y FROM T AS t group BY t.x + t.y

Pour ce faire dans Entity SQL :

SELECT k FROM T AS t GROUP BY (t.x + t.y) AS k

Référencement de colonnes (propriétés) de tables (collections)

Toutes les références de colonne dans Entity SQL doivent être qualifiées avec l’alias de table. La construction suivante (en supposant qu’il s’agit a d’une colonne de table Tvalide) est valide dans Transact-SQL, mais pas dans Entity SQL.

SELECT a FROM T

Le formulaire Entity SQL est

SELECT t.a AS A FROM T AS t

Les alias de table sont facultatifs dans la from clause. Le nom de la table est utilisé comme alias implicite. Entity SQL permet également le formulaire suivant :

SELECT Tab.a FROM Tab

Transact-SQL utilise la notation « ». pour référencer des colonnes d’une table (une ligne). Entity SQL étend cette notation (empruntée à partir de langages de programmation) pour prendre en charge la navigation via les propriétés d’un objet.

Par exemple, s’il s’agit p d’une expression de type Person, voici la syntaxe Entity SQL permettant de référencer la ville de l’adresse de cette personne.

p.Address.City

Aucune prise en charge de *

Transact-SQL prend en charge la syntaxe * non qualifiée en tant qu’alias pour l’ensemble de la ligne, et la syntaxe * qualifiée (t.*) comme raccourci pour les champs de cette table. En outre, Transact-SQL autorise un agrégat de nombres spéciaux(*), qui inclut des valeurs Null.

Entity SQL ne prend pas en charge la construction *. Transact-SQL requêtes du formulaire select * from T et select T1.* from T1, T2... peuvent être exprimées dans Entity SQL en tant que select value t from T as t et select value t1 from T1 as t1, T2 as t2..., respectivement. En outre, ces constructions gèrent l’héritage (substituabilité des valeurs), tandis que les select * variantes sont limitées aux propriétés de niveau supérieur du type déclaré.

Entity SQL ne prend pas en charge l’agrégation count(*) . Utilisez count(0) à la place.

Modifications apportées à Group By

Entity SQL prend en charge l’alias de group by clés. Les expressions dans la clause select et la clause having doivent faire référence aux group by clefs par le biais de ces alias. Par exemple, cette syntaxe Entity SQL :

SELECT k1, count(t.a), sum(t.a)
FROM T AS t
GROUP BY t.b + t.c AS k1

... équivaut à la commande Transact-SQL suivante :

SELECT b + c, count(*), sum(a)
FROM T
GROUP BY b + c

Agrégats basés sur des collections

Entity SQL prend en charge deux types d’agrégats.

Les agrégats basés sur des collections fonctionnent sur des collections et produisent le résultat agrégé. Celles-ci peuvent apparaître n’importe où dans la requête et ne nécessitent pas de group by clause. Par exemple:

SELECT t.a AS a, count({1,2,3}) AS b FROM T AS t

Entity SQL prend également en charge les agrégats de style SQL. Par exemple:

SELECT a, sum(t.b) FROM T AS t GROUP BY t.a AS a

Utilisation de la clause ORDER BY

Transact-SQL permet de spécifier des clauses ORDER BY uniquement dans le bloc SELECT .. FROM .. WHERE le plus haut. Dans Entity SQL, vous pouvez utiliser une expression imbriquée ORDER BY et elle peut être placée n’importe où dans la requête, mais l’ordre dans une requête imbriquée n’est pas conservé.

-- The following query will order the results by the last name  
SELECT C1.FirstName, C1.LastName  
        FROM AdventureWorks.Contact AS C1
        ORDER BY C1.LastName

-- In the following query ordering of the nested query is ignored.  
SELECT C2.FirstName, C2.LastName  
    FROM (SELECT C1.FirstName, C1.LastName  
        FROM AdventureWorks.Contact as C1  
        ORDER BY C1.LastName) as C2

Identificateurs

Dans Transact-SQL, la comparaison d’identificateurs est basée sur le classement de la base de données active. Dans Entity SQL, les identificateurs respectent toujours la casse et les accents (autrement dit, Entity SQL distingue les caractères accentués et non accentués ; par exemple, « a » n’est pas égal à « à »). Entity SQL traite les versions de lettres qui apparaissent de la même façon, mais qui proviennent de pages de code différentes comme des caractères différents. Pour plus d’informations, consultez Jeu de caractères d’entrée.

fonctionnalité Transact-SQL non disponible dans Entity SQL

La fonctionnalité Transact-SQL suivante n’est pas disponible dans Entity SQL.

DML
Entity SQL ne prend actuellement pas en charge les instructions DML (insertion, mise à jour, suppression).

Langage de définition de données (DDL)
Entity SQL ne prend pas en charge DDL dans la version actuelle.

Programmation impérative
Entity SQL ne prend pas en charge la programmation impérative, contrairement à Transact-SQL. Utilisez plutôt un langage de programmation.

Fonctions de regroupement
Entity SQL ne prend pas encore en charge les fonctions de regroupement (par exemple, CUBE, ROLLUP et GROUPING_SET).

Fonctions analytiques
Entity SQL ne prend pas (encore) en charge les fonctions analytiques.

Fonctions intégrées, opérateurs
Entity SQL prend en charge un sous-ensemble des fonctions et opérateurs intégrés de Transact-SQL. Ces opérateurs et fonctions sont susceptibles d’être pris en charge par les principaux fournisseurs de magasins. Entity SQL utilise les fonctions spécifiques au magasin déclarées dans un manifeste de fournisseur. En outre, Entity Framework vous permet de déclarer des fonctions de magasin intégrées et définies par l’utilisateur, pour que Entity SQL utilise.

Indicateurs
Entity SQL ne fournit pas de mécanismes pour les indicateurs de requête.

Regroupement des résultats de requêtes
Entity SQL ne prend pas en charge le traitement par lots des résultats de requête. Par exemple, ce qui suit est un Transact-SQL valide (envoyé sous forme de lot) :

SELECT * FROM products;
SELECT * FROM categories;

Toutefois, l’entité SQL équivalente n’est pas prise en charge :

SELECT value p FROM Products AS p;
SELECT value c FROM Categories AS c;

Entity SQL ne prend en charge qu’une seule instruction de requête produisant des résultats par commande.

Voir aussi

Last updated on 2025-06-20

Partager via