Usuário com melhor resposta
'AS' no Alias das tabelas

Pergunta
-
Olá,
Existe alguma diferença de performance entre usar o 'AS' ou não usar na atribuição de alias às tabelas?:
ex:
SELECT X.Id
FROM (SELECT {Group}.[Id] AS Id
FROM {Group} ) AS XVS.
SELECT X.Id
FROM (SELECT {Group}.[Id] AS Id
FROM {Group} ) XCumprimentos
- Editado Bruno F. Cantantes sexta-feira, 12 de fevereiro de 2016 11:32
Respostas
-
Não, nada de performance.
Ambas as sintaxes são equivalentes, assim como:
SELECT Id FROM (SELECT Id FROM Group)
Que é meio redundante, mas ok. Serve o propósito pois imagino que "{Group}" no seu exemplo seja um Join de Tabelas ou algo assim.
O principal motivo de usar o "AS" seria renomear campos ou tabelas em um SELECT, principalmente se houverem campos de nomes iguais em tabelas diferentes envolvidas no SELECT. Ao ocultar o argumento "AS" você não mudou o comportamento do SQL, apenas está usando um recurso que permite a você "escrever menos", mas em suma é o "AS" implícito.
O mesmo pode ser observado no "ORDER BY campo ASC". Se você não escrever o "ASC", o ORDER irá assumir que o "ASC" existe, e ordenará em ordem crescente. Não há impacto na performance em ambos os casos.
- Sugerido como Resposta Tiago_Neves sexta-feira, 12 de fevereiro de 2016 12:11
- Marcado como Resposta Marcos SJ sexta-feira, 12 de fevereiro de 2016 17:45
-
Não - em nenhum deles.
O SQL é a "linguagem" (o "L" é de language) que é usada para o SGBD (Sistema Gerneciador de Banco de Dados - MySql, SqlServer etc) interpretar o comando que deve ser executado. A execução em si faz parte das rotinas dele, mas a interpretação é a mesma (algumas palavras reservadas existem como LIMIT é para MySql assim como TOP é para o SqlServer).
O que quero dizer é, se eu falo para você "vá até a casa 1" ou "casa 1 : vá!" acaba, no processo sendo o mesmo - você irá pegar seu carro e ira até a casa 1. O interpretador vai montar o mesmo processo e DEPOIS executar a ação. Se você estiver usando o SqlServer, no management studio tem um recurso que você vê o "execution plan". O objetivo do SGBD é pegar um texto STRING que você escreveu usando SQL e montar um "execution plan" (plano de execução). Uma vez montado, o que estava escrito é irrelevante, ele vai processar.
Em resumo, NÃO, não há alteração de performance, e SIM - vale para todos os SGBD's.
- Marcado como Resposta Bruno F. Cantantes sábado, 13 de fevereiro de 2016 11:28
Todas as Respostas
-
Não, nada de performance.
Ambas as sintaxes são equivalentes, assim como:
SELECT Id FROM (SELECT Id FROM Group)
Que é meio redundante, mas ok. Serve o propósito pois imagino que "{Group}" no seu exemplo seja um Join de Tabelas ou algo assim.
O principal motivo de usar o "AS" seria renomear campos ou tabelas em um SELECT, principalmente se houverem campos de nomes iguais em tabelas diferentes envolvidas no SELECT. Ao ocultar o argumento "AS" você não mudou o comportamento do SQL, apenas está usando um recurso que permite a você "escrever menos", mas em suma é o "AS" implícito.
O mesmo pode ser observado no "ORDER BY campo ASC". Se você não escrever o "ASC", o ORDER irá assumir que o "ASC" existe, e ordenará em ordem crescente. Não há impacto na performance em ambos os casos.
- Sugerido como Resposta Tiago_Neves sexta-feira, 12 de fevereiro de 2016 12:11
- Marcado como Resposta Marcos SJ sexta-feira, 12 de fevereiro de 2016 17:45
-
-
Sim, imaginei. Mas é isso basicamente. Use o "AS" a vontade, sem ele, etc ...
A primeira etapa que o SQL faz é o PARSE do texto que você mandou pra ele, de lá ele identifica o que fazer, se você está renomeando a tabela com o argumento ou sem ele, só com o nome, o PARSER identifica a ação "renomear" (por assim dizer, lógico que esse não é o nome da ação, mas serve de exemplo) e trata aquela tabela pelo nome associado.
Se você ver como o SELECT funciona, fica fácil entender.
Digamos que o SELECT é isso:
SELECT t1.id AS cliid, t1.label AS clilabel, t2.id AS proid, t2.label AS prolabel FROM products AS t2 LEFT OUTER JOIN clients AS t1 ON t2.cli = t1.id WHERE t1.active = 1
Basicamente o que o SQL entende é:
1) Abrir tabela "products". (Ao abrir uma tabela, lembre-se que o servidor SQL Server é um programa, então tem uma classe que vai receber esta tabela). Ao abrir, essa tabela tem um nome associado, então a instância da classe que lê a tabela terá, na propriedade nome, o nome associado "t2".
2) Abrir a tabela "clients". Associada ao nome "t1".
3) Filtrar de "t1" apenas registros com "active = 1".
4) Fazer o Join de "t1" e "t2" pelas colunas marcadas. Esse Join é uma nova instância - uma "tabela virtual" que terá o resultado do SELECT.
5) Fornecer o ponteiro de leitura que será usado pela conexão para ler, linha a linha, da tabela resultante do Join.
6) Destruir as instâncias 1, 2 e 4 após término da leitura.
-
-
Não - em nenhum deles.
O SQL é a "linguagem" (o "L" é de language) que é usada para o SGBD (Sistema Gerneciador de Banco de Dados - MySql, SqlServer etc) interpretar o comando que deve ser executado. A execução em si faz parte das rotinas dele, mas a interpretação é a mesma (algumas palavras reservadas existem como LIMIT é para MySql assim como TOP é para o SqlServer).
O que quero dizer é, se eu falo para você "vá até a casa 1" ou "casa 1 : vá!" acaba, no processo sendo o mesmo - você irá pegar seu carro e ira até a casa 1. O interpretador vai montar o mesmo processo e DEPOIS executar a ação. Se você estiver usando o SqlServer, no management studio tem um recurso que você vê o "execution plan". O objetivo do SGBD é pegar um texto STRING que você escreveu usando SQL e montar um "execution plan" (plano de execução). Uma vez montado, o que estava escrito é irrelevante, ele vai processar.
Em resumo, NÃO, não há alteração de performance, e SIM - vale para todos os SGBD's.
- Marcado como Resposta Bruno F. Cantantes sábado, 13 de fevereiro de 2016 11:28
-