Início / dba / Perguntas / 16516
Accepted
IcySnow
Asked: 2012-04-15 07:06:17 +0800 CST

Aliases de subconsultas iguais aos aliases de consultas principais

  • 772

Eu tenho uma consulta SQL cujos aliases são os mesmos que alguns dos aliases de sua subconsulta.

Por exemplo:

select *
from ROOM r
where ...
         (
              select *
              from ROAD r
              where ...
         )

Isso funciona bem, pois o alias da subconsulta parece ocultar o principal.

  1. Funcionará assim em todos os casos?
  2. Será que algum dia obterei resultados indefinidos?
  3. Se não há problema em fazer isso, como posso fazer uma referência à consulta principal r?
sql-server t-sql

2 respostas

  1. Best Answer

    Não há problema em subconsultas aninhadas usarem os mesmos aliases usados ​​na consulta pai, embora possa ser um pouco confuso para alguém lendo o código. O namespace para aliases em uma subconsulta aninhada é separado do namespace no pai. Por exemplo, a consulta abaixo tem uma subconsulta aninhada bque também possui um alias busado nela. Isso seria potencialmente confuso para o programador, mas tudo bem com o mecanismo DBMS:

       select a.foo
          ,b.bar
          ,b.BarCount
      from (select b.bar
                  ,count (*) as BarCount
              from BarTable b
              join OtherTable o
                on b.OtherTableID = o.OtherTableID
             group by b.bar) b
      join Foobar a
        on a.bar = b.bar

    Em uma subconsulta correlacionada, você tem acesso aos aliases do pai, portanto, os aliases devem ser exclusivos na consulta pai e na subconsulta correlacionada. Se pegarmos uma subconsulta correlacionada como a abaixo, teremos um único espaço de nome global compartilhado entre a consulta pai e a subconsulta correlacionada:

    select a.foo
      ,b.bar
  from Foobar a
  join Bar b
    on b.FooBarID = a.FooBarID
 where not exists
       (select 1
          from Bar b2
         where b2.BarCategoryID = b.BarCategoryID
           and b2.BarDate > b.BarDate)

    A subconsulta correlacionada não possui um alias, pois não participa de uma junção como tal 1 . As referências be b2para barestão disponíveis para a subconsulta, pois as subconsultas correlacionadas compartilham seu namespace para aliases com o pai.

    1 Observe que o otimizador pode optar por usar operadores de junção dentro do plano nos bastidores, embora a operação real especificada seja uma subconsulta correlacionada e não uma junção em uma subconsulta aninhada.

    • 22

  2. ConcernedOfTunbridgeWells, você escreve (ênfase minha): "Em uma subconsulta correlacionada, você tem acesso aos aliases do pai, portanto, os aliases devem ser exclusivos na consulta pai e na subconsulta correlacionada".

    Eu não acredito que a singularidade seja necessária. Acredito que, se um alias for usado em uma subconsulta correlacionada como um nome de correlação, bem como um alias de tabela na consulta externa, o alias na subconsulta terá precedência.

    Exemplo:

    CREATE TABLE #T (A INT)
CREATE TABLE #U (A INT)
CREATE TABLE #V (A INT)

INSERT INTO #T (A) VALUES (1), (2), (3)
INSERT INTO #U (A) VALUES (2), (3), (4)
INSERT INTO #V (A) VALUES (3), (4), (5)

SELECT
    T1.A
FROM
    #T AS T1
    INNER JOIN #U AS T2 ON T1.A = T2.A
WHERE
    EXISTS (SELECT * FROM #V AS T2 WHERE T1.A = T2.A)

    A saída é "3": as tabelas T e U têm 2 e 3 em comum, mas o WHEREpredicado filtra ainda mais as linhas retornadas para 3, e 2 não existe em V.

    • 5

relate perguntas