none
'AS' no Alias das tabelas RRS feed

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

    VS.


    SELECT X.Id
    FROM (SELECT {Group}.[Id] AS Id
                   FROM {Group} ) X

    Cumprimentos


    sexta-feira, 12 de fevereiro de 2016 11:11

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
    sexta-feira, 12 de fevereiro de 2016 11:26
  • 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.

    sexta-feira, 12 de fevereiro de 2016 15:59

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
    sexta-feira, 12 de fevereiro de 2016 11:26
  • Sammuel, muito obrigado pela resposta. O exemplo é só para contextualizar ;).
    sexta-feira, 12 de fevereiro de 2016 11:35
  • 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.

    sexta-feira, 12 de fevereiro de 2016 12:10
  • Esta questão é transversal entre DBMS's? Ou seja não existe nenhuma diferença de performance entre usar e não usar o 'AS' em ex: Oracle, mysql, postgresql, sqlite?
    sexta-feira, 12 de fevereiro de 2016 12:21
  • 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.

    sexta-feira, 12 de fevereiro de 2016 15:59
  • Mais uma vez obrigado Sammuel.
    sábado, 13 de fevereiro de 2016 11:29