Hur entitets-SQL skiljer sig från Transact-SQL

Artikel
03/05/2024

Den här artikeln beskriver skillnaderna mellan Entity SQL och Transact-SQL.

Stöd för arv och relationer

Entitets-SQL fungerar direkt med konceptuella entitetsscheman och stöder konceptuella modellfunktioner som arv och relationer.

När du arbetar med arv är det ofta användbart att välja instanser av en undertyp från en samling supertypinstanser. Oftype-operatorn i Entity SQL (liknar oftype i C#-sekvenser) tillhandahåller den här funktionen.

Stöd för samlingar

Entitets-SQL behandlar samlingar som förstklassiga entiteter. Till exempel:

Samlingsuttryck är giltiga i en from sats.
in och exists underfrågor har generaliserats för att tillåta alla samlingar.

En underfråga är en typ av samling. e1 in e2 och exists(e) är entitets-SQL-konstruktionerna för att utföra dessa åtgärder.
Ange åtgärder, till exempel union, intersectoch except, fungerar nu på samlingar.
Kopplingar fungerar på samlingar.

Stöd för uttryck

Transact-SQL har underfrågor (tabeller) och uttryck (rader och kolumner).

För att stödja samlingar och kapslade samlingar gör Entity SQL allt till ett uttryck. Entitets-SQL är mer komposterbar än Transact-SQL – varje uttryck kan användas var som helst. Frågeuttryck resulterar alltid i samlingar av de planerade typerna och kan användas var som helst där ett samlingsuttryck tillåts. Information om Transact-SQL-uttryck som inte stöds i entitets-SQL finns i Uttryck som inte stöds.

Följande är alla giltiga SQL-frågor för entitet:

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

Enhetlig behandling av underfrågor

Med tanke på dess betoning på tabeller utför Transact-SQL kontextuell tolkning av underfrågor. Till exempel anses en underfråga i from -satsen vara en flermängd (tabell). Men samma underfråga som används i select -satsen anses vara en skalär underfråga. På samma sätt anses en underfråga som används på vänster sida av en in operator vara en skalär underfråga, medan den högra sidan förväntas vara en delfråga för flera enheter.

Entitets-SQL eliminerar dessa skillnader. Ett uttryck har en enhetlig tolkning som inte är beroende av den kontext i vilken det används. Entitets-SQL anser att alla underfrågor är underfrågor med flera uppsättningar. Om ett skalärt värde önskas från underfrågan tillhandahåller Entity SQL operatorn anyelement som körs på en samling (i det här fallet underfrågan) och extraherar ett singleton-värde från samlingen.

Undvika implicita tvång för underfrågor

En relaterad bieffekt av enhetlig behandling av underfrågor är implicit konvertering av underfrågor till skalära värden. I Transact-SQL konverteras en raduppsättning (med ett enda fält) implicit till ett skalärt värde vars datatyp är fältets.

Entitets-SQL stöder inte detta implicita tvång. Entitets-SQL tillhandahåller operatorn ANYELEMENT för att extrahera ett singleton-värde från en samling och en select value sats för att undvika att skapa en radomslutning under ett frågeuttryck.

Välj värde: Undvika implicit radomslutning

Select-satsen i en Transact-SQL-underfråga skapar implicit en radomslutning runt objekten i -satsen. Det innebär att vi inte kan skapa samlingar med skalärer eller objekt. Transact-SQL tillåter ett implicit tvång mellan ett rowtype med ett fält och ett singleton-värde av samma datatyp.

Entitets-SQL tillhandahåller select value -satsen för att hoppa över den implicita radkonstruktionen. Endast ett objekt kan anges i en select value sats. När en sådan sats används konstrueras ingen radomslutning runt objekten select i -satsen, och en samling av önskad form kan skapas, till exempel select value a.

Entitets-SQL tillhandahåller även radkonstruktorn för att konstruera godtyckliga rader. select tar ett eller flera element i projektionen och resulterar i en datapost med fält:

select a, b, c

Vänster korrelation och alias

I Transact-SQL kan uttryck i ett visst omfång (en enskild sats som eller from) inte referera till uttryck som select definierats tidigare i samma omfång. Vissa dialekter av SQL (inklusive Transact-SQL) stöder begränsade former av dessa i from -satsen.

Entitets-SQL generaliserar vänsterkorrelationer i from -satsen och behandlar dem enhetligt. Uttryck i from -satsen kan referera till tidigare definitioner (definitioner till vänster) i samma sats utan att behöva ytterligare syntax.

Entitets-SQL medför också ytterligare begränsningar för frågor som involverar group by satser. Uttryck i select -satsen och having -satsen för sådana frågor kan bara referera till group by nycklarna via deras alias. Följande konstruktion är giltig i Transact-SQL men finns inte i entitets-SQL:

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

Så här gör du i Entitets-SQL:

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

Referera till kolumner (egenskaper) för tabeller (samlingar)

Alla kolumnreferenser i Entitets-SQL måste vara kvalificerade med tabellaliaset. Följande konstruktion (förutsatt att det a är en giltig kolumn i tabellen T) är giltig i Transact-SQL men inte i entitets-SQL.

SELECT a FROM T

Entitets-SQL-formuläret är

SELECT t.a AS A FROM T AS t

Tabellaliasen är valfria i from -satsen. Namnet på tabellen används som implicit alias. Entitets-SQL tillåter även följande formulär:

SELECT Tab.a FROM Tab

Transact-SQL använder notationen "." för att referera till kolumner i (en rad med) en tabell. Entitets-SQL utökar den här notationen (lånad från programmeringsspråk) för att stödja navigering via egenskaperna för ett objekt.

Om till exempel p är ett uttryck av typen Person är följande entitets-SQL-syntax för att referera till orten för adressen till den här personen.

p.Address.City

Inget stöd för *

Transact-SQL stöder den okvalificerade * syntaxen som ett alias för hela raden och den kvalificerade * syntaxen (t.*) som en genväg för fälten i tabellen. Dessutom tillåter Transact-SQL ett särskilt antal(*) aggregeringar, som innehåller nullvärden.

Entitets-SQL stöder inte *-konstruktionen. Transact-SQL-frågor i formuläret select * from T och select T1.* from T1, T2... kan uttryckas i Entity SQL som select value t from T as t respektive select value t1 from T1 as t1, T2 as t2.... Dessutom hanterar dessa konstruktioner arv (utbytbara värden), medan varianterna select * är begränsade till egenskaper på den högsta nivån för den deklarerade typen.

Entitets-SQL stöder inte aggregeringen count(*) . Använd count(0) i stället.

Ändringar i gruppera efter

Entitets-SQL stöder alias för group by nycklar. Uttryck i select -satsen och having -satsen måste referera till group by nycklarna via dessa alias. Till exempel den här SQL-syntaxen för entitet:

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

... motsvarar följande Transact-SQL:

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

Samlingsbaserade aggregeringar

Entitets-SQL stöder två typer av aggregeringar.

Samlingsbaserade aggregeringar fungerar på samlingar och ger det aggregerade resultatet. Dessa kan visas var som helst i frågan och kräver group by ingen sats. Till exempel:

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

Entitets-SQL har också stöd för aggregat i SQL-format. Till exempel:

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

ORDER BY-satsanvändning

Transact-SQL tillåter ORDER BY att satser endast anges i det översta SELECT .. FROM .. WHERE blocket. I Entitets-SQL kan du använda ett kapslat ORDER BY uttryck och det kan placeras var som helst i frågan, men ordningen i en kapslad fråga bevaras inte.

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

Identifiers

I Transact-SQL baseras identifierarjämförelsen på sortering av den aktuella databasen. I Entitets-SQL är identifierare alltid skiftlägesokänsliga och dekorkänsliga (det vill säga entitets-SQL skiljer mellan accenttecken och oaccenterade tecken. Till exempel är "a" inte lika med "ấ"). Entitets-SQL behandlar versioner av bokstäver som ser likadana ut men som kommer från olika kodsidor som olika tecken. Mer information finns i Indatateckenuppsättning.

Transact-SQL-funktioner är inte tillgängliga i entitets-SQL

Följande Transact-SQL-funktioner är inte tillgängliga i entitets-SQL.

DML
Entitets-SQL har för närvarande inget stöd för DML-instruktioner (infoga, uppdatera, ta bort).

DDL
Entitets-SQL har inget stöd för DDL i den aktuella versionen.

Imperativ programmering
Entitets-SQL har inget stöd för imperativ programmering, till skillnad från Transact-SQL. Använd ett programmeringsspråk i stället.

Grupperingsfunktioner
Entitets-SQL har ännu inte stöd för grupperingsfunktioner (till exempel CUBE, ROLLUP och GROUPING_SET).

Analysfunktioner
Entitets-SQL har inte (ännu) stöd för analysfunktioner.

Inbyggda funktioner, operatorer
Entitets-SQL stöder en delmängd av Transact-SQL:s inbyggda funktioner och operatorer. Dessa operatorer och funktioner kommer sannolikt att stödjas av de större butiksleverantörerna. Entitets-SQL använder de butiksspecifika funktioner som deklareras i ett providermanifest. Med Entity Framework kan du dessutom deklarera inbyggda och användardefinierade befintliga lagringsfunktioner som entitets-SQL kan använda.

Tips
Entitets-SQL tillhandahåller inte mekanismer för frågetips.

Batchbearbetning av frågeresultat
Entitets-SQL stöder inte batchbearbetning av frågeresultat. Följande är till exempel giltigt Transact-SQL (skicka som en batch):

SELECT * FROM products;
SELECT * FROM categories;

Motsvarande entitets-SQL stöds dock inte:

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

Entitets-SQL stöder endast en resultatskapande frågesats per kommando.

Dela via