Identificadores (Entity SQL)
Os identificadores são usados no Entity SQL para representar aliases de expressão de consulta, referências de variáveis, propriedades de objetos, funções e assim por diante. O Entity SQL 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 cotados
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 colchetes tornam-se parte do identificador, incluindo todos os espaços em branco.
Um identificador entre aspas não pode incluir os seguintes caracteres:
Nova linha.
Retorno de carro.
Separadores.
Backspace.
Colchetes adicionais (ou seja, colchetes dentro dos colchetes que delineiam 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á desambiguá-la 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 de ponto (.).
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]" é o identificador:
SELECT t from ts as t WHERE t.[abc]]] == 2
Para semântica de comparação de identificadores entre aspas, consulte Conjunto de caracteres de entrada.
Regras de aliasing
Recomendamos especificar aliases em consultas Entity SQL sempre que necessário, incluindo as seguintes construções Entity SQL:
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
Aliases válidos no Entity SQL são qualquer identificador simples ou identificador entre aspas.
Geração Alias
Se nenhum alias for especificado em uma expressão de consulta Entity SQL, 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 é especificado) for um identificador simples ou entre aspas, esse identificador será usado como o alias. Por exemplo,
ROW(a, [b])passa aROW(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 o alias. Por exemplo,
ROW(a.a1, b.[b1])passa aROW(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á pela compilação mesmo que haja um alias explícito ou implícito do 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 através da leitura do código.
SELECT 1 AS X, 2 AS X …
Regras de escopo
O Entity SQL define regras de escopo que determinam quando variáveis específicas são visíveis na linguagem de consulta. Algumas expressões ou declaraçõ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 de outra pode ocultar seu antecessor.
Quando os nomes são definidos em uma consulta Entity SQL, 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 do início e do término de um escopo, 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 do Entity SQL que também introduzem escopos. Quando os escopos são aninhados, podem ser feitas referências a nomes definidos no escopo mais interno, que contém a referência. Também podem ser feitas referências a quaisquer nomes definidos em quaisquer âmbitos externos. Quaisquer dois escopos definidos dentro do mesmo escopo são considerados escopos irmãos. Não é possível fazer referências a nomes definidos dentro de 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 de escopos declarados dentro desse escopo referem-se apenas ao nome recém-declarado. O nome no escopo externo está oculto.
Mesmo dentro do mesmo âmbito, 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 a 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 Entity SQL introduz um novo escopo. Os nomes definidos na cláusula FROM são introduzidos no escopo from por ordem de aparição, da esquerda para a direita. Na lista de junção, as expressões podem referir-se 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 from. Eles devem ser sempre referenciados pelo nome qualificado pelo alias. Normalmente, todas as partes da expressão SELECT são consideradas dentro do escopo from.
A cláusula GROUP BY introduz igualmente um novo âmbito de aplicação 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 from. No entanto, quando uma cláusula GROUP BY é usada, a cláusula select-list (projeção), a cláusula HAVING e a cláusula ORDER BY são consideradas dentro do escopo do grupo, e não do escopo from. Os agregados recebem tratamento especial, conforme descrito na lista com marcadores a seguir.
A seguir estão notas adicionais sobre escopos:
A lista de seleção pode introduzir novos nomes no escopo, em ordem. As expressões de projeção à direita podem referir-se a nomes projetados à esquerda.
A cláusula ORDER BY pode referir-se a nomes (aliases) especificados na lista de seleção.
A ordem de avaliação das 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 HAVER, cláusula SELECT e, finalmente, a cláusula ORDER BY.
Manuseamento de agregados
O Entity SQL suporta duas formas de agregação: agregações baseadas em coleção e agregações baseadas em grupo. As agregações baseadas em coleção são a construção preferida no Entity SQL, e as agregações baseadas em grupo têm suporte para compatibilidade com SQL.
Ao resolver uma agregação, o Entity SQL primeiro tenta tratá-la 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))