Compartilhar via


Identificadores (Entity SQL)

Os identificadores são usados no Entity SQL para representar aliases de expressão de consulta, referências variáveis, propriedades de objetos, funções e assim por diante. O SQL da entidade fornece dois tipos de identificadores: identificadores simples e identificadores entre aspas.

Identificadores simples

Um identificador simples no Entity SQL é uma sequência de caracteres alfanuméricos e sublinhados. O primeiro caractere do identificador deve ser um caractere alfabético (a-z ou A-Z).

Identificadores entre aspas

Um identificador entre aspas é qualquer sequência de caracteres entre colchetes ([]). Os identificadores entre aspas permitem especificar identificadores com caracteres que não são válidos em identificadores. Todos os caracteres entre os colchetes tornam-se parte do identificador, incluindo todo o espaço em branco.

Um identificador entre aspas não pode incluir os seguintes caracteres:

  • Newline.

  • O carro retorna.

  • Separadores.

  • Backspace.

  • Colchetes adicionais (ou seja, colchetes dentro dos colchetes que delineam o identificador).

Um identificador entre aspas pode incluir caracteres Unicode.

Os identificadores entre aspas permitem criar caracteres de nome de propriedade que não são válidos em identificadores, conforme ilustrado no exemplo a seguir:

SELECT c.ContactName AS [Contact Name] FROM customers AS c

Você também pode usar identificadores entre aspas para especificar um identificador que seja uma palavra-chave reservada do Entity SQL. Por exemplo, se o tipo Email tiver uma propriedade chamada "From", você poderá desambiguar da palavra-chave reservada FROM usando colchetes, da seguinte maneira:

SELECT e.[From] FROM emails AS e

Você pode usar um identificador entre aspas no lado direito de um operador dot (.).

SELECT t FROM ts as t WHERE t.[property] == 2

Para usar o colchete em um identificador, adicione um colchete extra. No exemplo a seguir "abc]" está o identificador:

SELECT t from ts as t WHERE t.[abc]]] == 2

Para obter a semântica de comparação do identificador entre aspas, consulte Conjunto de Caracteres de Entrada.

Regras de aliasing

Recomendamos especificar aliases em consultas SQL de entidade sempre que necessário, incluindo os seguintes constructos de SQL de entidade:

  • Campos de um construtor de linha.

  • Itens na cláusula FROM de uma expressão de consulta.

  • Itens na cláusula SELECT de uma expressão de consulta.

  • Itens na cláusula GROUP BY de uma expressão de consulta.

Aliases válidos

Os aliases válidos no Entity SQL são qualquer identificador simples ou identificador entre aspas.

Geração de alias

Se nenhum alias for especificado em uma expressão de consulta SQL de entidade, o Entity SQL tentará gerar um alias com base nas seguintes regras simples:

  • Se a expressão de consulta (para a qual o alias não for especificado) for um identificador simples ou entre aspas, esse identificador será usado como alias. Por exemplo, ROW(a, [b]) se tornará ROW(a AS a, [b] AS [b]).

  • Se a expressão de consulta for uma expressão mais complexa, mas o último componente dessa expressão de consulta for um identificador simples, esse identificador será usado como alias. Por exemplo, ROW(a.a1, b.[b1]) se tornará ROW(a.a1 AS a1, b.[b1] AS [b1]).

Recomendamos que você não use aliasing implícito se quiser usar o nome do alias mais tarde. Sempre que os aliases (implícitos ou explícitos) entrarem em conflito ou forem repetidos no mesmo escopo, haverá um erro de compilação. Um alias implícito passará a compilação mesmo se houver um alias explícito ou implícito com o mesmo nome.

Os aliases implícitos são gerados automaticamente com base na entrada do usuário. Por exemplo, a linha de código a seguir gerará NAME como um alias para ambas as colunas e, portanto, entrará em conflito.

SELECT product.NAME, person.NAME

A linha de código a seguir, que usa aliases explícitos, também falhará. No entanto, a falha será mais aparente lendo o código.

SELECT 1 AS X, 2 AS X …

Regras de escopo

O SQL de entidade define regras de escopo que determinam quando variáveis específicas estão visíveis na linguagem de consulta. Algumas expressões ou instruções introduzem novos nomes. As regras de escopo determinam onde esses nomes podem ser usados e quando ou onde uma nova declaração com o mesmo nome que outra pode ocultar seu antecessor.

Quando os nomes são definidos em uma consulta SQL de entidade, eles são definidos dentro de um escopo. Um escopo abrange uma região inteira da consulta. Todas as expressões ou referências de nome dentro de um determinado escopo podem ver nomes definidos dentro desse escopo. Antes que um escopo comece e depois de terminar, os nomes definidos dentro do escopo não podem ser referenciados.

Os escopos podem ser aninhados. Partes do Entity SQL introduzem novos escopos que abrangem regiões inteiras, e essas regiões podem conter outras expressões SQL de entidade que também introduzem escopos. Quando os escopos são aninhados, as referências podem ser feitas a nomes definidos no escopo mais interno, que contém a referência. Referências também podem ser feitas a todos os nomes definidos em quaisquer escopos externos. Quaisquer dois escopos definidos no mesmo escopo são considerados escopos irmãos. Não é possível fazer referências a nomes definidos em escopos irmãos.

Se um nome declarado em um escopo interno corresponder a um nome declarado em um escopo externo, as referências dentro do escopo interno ou dentro dos escopos declarados dentro desse escopo referem-se apenas ao nome recém-declarado. O nome no escopo externo está oculto.

Mesmo dentro do mesmo escopo, os nomes não podem ser referenciados antes de serem definidos.

Nomes globais podem existir como parte do ambiente de execução. Isso pode incluir nomes de coleções persistentes ou variáveis de ambiente. Para que um nome seja global, ele deve ser declarado no escopo mais externo.

Os parâmetros não estão em um escopo. Como as referências aos parâmetros incluem sintaxe especial, os nomes dos parâmetros nunca colidirão com outros nomes na consulta.

Expressões de consulta

Uma expressão de consulta SQL de entidade apresenta um novo escopo. Os nomes definidos na cláusula FROM são introduzidos no escopo do escopo em ordem de aparência, da esquerda para a direita. Na lista de junção, as expressões podem se referir a nomes que foram definidos anteriormente na lista. As propriedades públicas (campos e assim por diante) dos elementos identificados na cláusula FROM não são adicionadas ao escopo. Eles devem ser sempre referenciados pelo nome qualificado por alias. Normalmente, todas as partes da expressão SELECT são consideradas dentro do escopo.

A cláusula GROUP BY também introduz um novo escopo irmão. Cada grupo pode ter um nome de grupo que se refere à coleção de elementos no grupo. Cada expressão de agrupamento também introduzirá um novo nome no escopo do grupo. Além disso, a agregação de aninhamento (ou o grupo nomeado) também é adicionada ao escopo. As próprias expressões de agrupamento estão dentro do escopo. No entanto, quando uma cláusula GROUP BY é usada, a cláusula select-list (projeção), HAVING e ORDER BY são consideradas dentro do escopo do grupo e não do escopo. As agregações recebem tratamento especial, conforme descrito na lista com marcadores a seguir.

Veja a seguir notas adicionais sobre escopos:

  • A lista de seleção pode introduzir novos nomes no escopo, em ordem. Expressões de projeção à direita podem se referir a nomes projetados à esquerda.

  • A cláusula ORDER BY pode se referir a nomes (aliases) especificados na lista de seleção.

  • A ordem de avaliação de cláusulas dentro da expressão SELECT determina a ordem em que os nomes são introduzidos no escopo. A cláusula FROM é avaliada primeiro, seguida pela cláusula WHERE, cláusula GROUP BY, cláusula HAVING, cláusula SELECT e, por fim, a cláusula ORDER BY.

Manipulação de agregação

O SQL de entidade dá suporte a duas formas de agregações: agregações baseadas em coleção e agregações baseadas em grupo. As agregações baseadas em coleção são o constructo preferencial no SQL da Entidade e as agregações baseadas em grupo têm suporte para compatibilidade com SQL.

Ao resolver uma agregação, o Entity SQL tenta tratá-la pela primeira vez como uma agregação baseada em coleção. Se isso falhar, o Entity SQL transformará a entrada de agregação em uma referência à agregação de aninhamento e tentará resolver essa nova expressão, conforme ilustrado no exemplo a seguir.

AVG(t.c) becomes AVG(group..(t.c))

Consulte também