DE (Entity SQL)
Especifica a coleção usada em instruções SELECT.
Sintaxe
FROM expression [ ,...n ] AS C
Argumentos
expression
Qualquer expressão de consulta válida que produzir uma coleção para usar como uma fonte em uma instrução de SELECT .
Comentários
Uma cláusula de FROM é uma lista separada por vírgulas de um ou mais itens da cláusula de FROM . A cláusula de FROM pode ser usada para especificar uma ou mais fontes para uma declaração de SELECT . A forma mais simples de uma cláusula de FROM é uma única expressão de consulta que identifica uma coleção e um alias usadas como a origem em uma instrução de SELECT , conforme ilustrado no exemplo a seguir:
FROM C as c
Itens de cláusula
Cada item de cláusula FROM refere-se a uma coleção de origem na consulta de Entity SQL. O Entity SQL suporta as seguintes classes de itens de cláusula FROM: itens simples de cláusula FROM, itens de cláusula JOIN FROM e itens da cláusula APPLY FROM. Cada um desses itens de cláusula de FROM é descrito em detalhes nas seções seguintes.
Simples de item da cláusula
O item mais simples de cláusula de FROM é uma única expressão que identifica uma coleção e um alias. A expressão pode ser simplesmente um conjunto de entidades, ou um subconsulta, ou qualquer outra expressão que é um tipo de coleção. A seguir, é mostrado um exemplo:
LOB.Customers as c
A especificação do alias é opcional. Uma especificação alternativa de acima do item da cláusula pode ser a seguinte:
LOB.Customers
Se nenhum alias for especificada, o Entity SQL tenta gerar um alias com base na expressão de coleção.
JUNTE-SE de item da cláusula
Um item da cláusula de JOIN FROM representa uma associação entre dois itens a cláusula de FROM . O Entity SQL dá suporte a junções cruzadas, junções internas, junções externas à esquerda e à direita e junções externas completas. Todas essas junções têm suporte semelhante ao suporte a elas no Transact-SQL. Como no Transact-SQL, os dois itens de cláusula FROM, em JOIN precisam ser independentes. Isto é, não podem ser correlacionados. CROSS APPLY ou OUTER APPLY podem ser usados para esses casos.
Cruzam A adição
Uma expressão de consulta de CROSS JOIN gerencia o produto cartesiano das duas coleções, como ilustrado no exemplo a seguir:
FROM C AS c CROSS JOIN D as d
Interno join
INNER JOIN gerencia um produto cartesiano restrito das duas coleções, como ilustrado no exemplo a seguir:
FROM C AS c [INNER] JOIN D AS d ON e
A expressão de consulta anterior processa uma combinação de cada elemento da coleção à esquerda emparelhado com cada elemento da coleção à direita, onde a condição de ON é verdadeira. Se nenhuma condição de ON for especificada, INNER JOIN degenerado a CROSS JOIN.
Left outer join e externo direito join
Uma expressão de consulta de OUTER JOIN gerencia um produto cartesiano restrito das duas coleções, como ilustrado no exemplo a seguir:
FROM C AS c LEFT OUTER JOIN D AS d ON e
A expressão de consulta anterior processa uma combinação de cada elemento da coleção à esquerda emparelhado com cada elemento da coleção à direita, onde a condição de ON é verdadeira. Se a condição de ON for falsa, a expressão ainda processa uma única instância do elemento à esquerda emparelhado contra o elemento à direita, com o valor de zero.
RIGHT OUTER JOIN pode ser expresso de maneira similar.
Externo completo join
FULL OUTER JOIN explícito gerencia um produto cartesiano restrito das duas coleções como ilustrado no exemplo a seguir:
FROM C AS c FULL OUTER JOIN D AS d ON e
A expressão de consulta anterior processa uma combinação de cada elemento da coleção à esquerda emparelhado com cada elemento da coleção à direita, onde a condição de ON é verdadeira. Se a condição de ON for falsa, a expressão ainda processa uma instância do elemento à esquerda emparelhado contra o elemento à direita, com o valor de zero. Também processa uma instância do elemento à direita emparelhado contra o elemento à esquerda, com o valor de zero.
Observação
Para preservar compatibilidade com SQL-92, no Transact-SQL a palavra-chave OUTER é opcional. Portanto, LEFT JOIN, RIGHT JOIN, e FULL JOIN são sinônimos para LEFT OUTER JOIN, RIGHT OUTER JOIN, e FULL OUTER JOIN.
APPLY o item da cláusula
O Entity SQL dá suporte a dois tipos de agregaçõesAPPLY: CROSS APPLY e OUTER APPLY.
CROSS APPLY gerencia um emparelhamento exclusivo de cada elemento da coleção à esquerda com um elemento da coleção gerada avaliando a expressão à direita. Com CROSS APPLY, a expressão à direita funcional é dependente no elemento à esquerda, conforme ilustrado no exemplo associado de coleção:
SELECT c, f FROM C AS c CROSS APPLY c.Assoc AS f
O comportamento de CROSS APPLY é semelhante à lista de associação. Se a expressão à direita é avaliada como uma coleção vazia, CROSS APPLY não gerencia nenhum pairings para essa instância do elemento à esquerda.
OUTER APPLY é semelhante a CROSS APPLY, a não ser que um emparelhamento ainda é gerado mesmo quando a expressão à direita é avaliada como uma coleção vazia. O código a seguir é um exemplo de OUTER APPLY:
SELECT c, f FROM C AS c OUTER APPLY c.Assoc AS f
Observação
Ao contrário do Transact-SQL, não há necessidade de uma etapa de desaninhamento explícita no Entity SQL.
Observação
Os operadores CROSS e OUTER APPLY foram introduzidos no SQL Server 2005. Em alguns casos, o canal de consulta pode gerar Transact-SQL que contém CROSS APPLY e/ou operadores de OUTER APPLY . Porque alguns provedores back-end, incluindo versões do SQL Server anteriores ao SQL Server 2005, não dão suporte para esses operadores, essas consultas podem não ser executadas nesses provedores back-end.
Alguns cenários típicos que podem resultar na presença de CROSS APPLY e/ou operadores de OUTER APPLY na saída consulte são os seguintes: um subconsulta correlacionado com paginação; AnyElement sobre um subconsulta correlacionado ou em uma coleção gerada por navegação; LINQ consulta que uso que agrupa os métodos que aceitam um seletor do elemento; uma consulta em que CROSS APPLY ou OUTER APPLY são especificados explicitamente; uma consulta que tenha uma compilação de DEREF sobre uma compilação de REF .
Várias coleções na cláusula
A cláusula de FROM pode conter mais de uma coleção separados por vírgulas. Nesses casos, coleções são assumidas para ser agrupadas. Pense nesses CRUZ como uma maneira de n- JOIN.
No exemplo a seguir, C e D são coleções independentes, mas c.Names depende de C.
FROM C AS c, D AS d, c.Names AS e
O exemplo anterior é logicamente equivalente ao exemplo a seguir:
FROM (C AS c JOIN D AS d) CROSS APPLY c.Names AS e
Correlação esquerda
Os itens na cláusula FROM podem se referir aos itens especificados nas cláusulas anteriores. No exemplo a seguir, C e D coleções são independentes, mas c.Names é dependente em C:
from C as c, D as d, c.Names as e
Isso é logicamente equivalente a:
from (C as c join D as d) cross apply c.Names as e
Semântica
Logicamente, coleções na cláusula FROM são assumidas para ser parte de n- a cruz de maneira joins a não ser que no caso de uma maneira 1 percorrer se junte). Alias na cláusula FROM são processadas esquerda para a direita, e adicionadas ao escopo atual para referência posterior. A cláusula de FROM é assumida para gerar um multiset de linhas. Haverá um campo para cada item na cláusula FROM que representa um único elemento do item da coleção.
A cláusula de FROM gerencia logicamente um multiset das linhas da linha de tipo (c, d, e) onde os campos c, d, e e são considerados para ser do tipo de elemento de C, de D, e de c.Names.
O Entity SQL introduz um alias para cada item de cláusula FROM simples no escopo. Por exemplo, o seguinte snippet da cláusula, os nomes são introduzidos no escopo c, d, e E.
from (C as c join D as d) cross apply c.Names as e
No Entity SQL (ao contrário do Transact-SQL), a cláusula FROM introduz apenas os alias no escopo. Todas as referências às colunas (propriedades) dessas coleções devem ser qualificados com o alias.
Levantando chaves de consultas aninhadas
Determinados tipos de consultas que exigem gerar chaves de uma consulta aninhada não são suportados. Por exemplo, a seguinte consulta é válido:
select c.Orders from Customers as c
No entanto, a consulta a seguir é inválido, porque a consulta aninhada não tem nenhuma chaves:
select {1} from {2, 3}