O aliasing de tabela é uma prática ruim?

O aliasing de tabela é uma prática comum e útil.

• Ele economiza pressionamentos de tecla ao fazer referência a colunas em qualquer lugar da sua consulta.
• Ele melhora a legibilidade do seu SQL quando você faz referência a muitas tabelas. Aliases permitem que você dê a essas tabelas um nome curto e um pequeno significado de como elas estão sendo usadas.
• É necessário até mesmo quando você ingressa em uma tabela ou quando ingressa na mesma tabela várias vezes. Isso é feito para que o otimizador de consultas saiba a qual tabela você está se referindo ao mencionar uma coluna.

O extrato de relatório a seguir ilustra bem todos os pontos acima:

INSERT INTO reporting.txns_extract
SELECT 
    -- 30+ columns snipped
    -- 
    -- Would you want to type out full table names for each 
    -- column here?
FROM 
    -- ... and in the JOIN conditions here?
                billing.financial_transactions  ft_cdi   -- alias required here
    INNER JOIN  
                billing.cash_application_links  cal
            ON  ft_cdi.key_num = cal.applied_ft_key_num
    INNER JOIN  
                billing.financial_transactions  ft_pmt   -- alias required here
            ON  cal.owner_key_num = ft_pmt.key_num
    LEFT OUTER JOIN
                billing.invoice_lines           invl
            ON  ft_cdi.key_num = invl.invoice_key_num
    LEFT OUTER JOIN
                billing.charges                 chrg
            ON  invl.creator_key_num = chrg.key_num
    LEFT OUTER JOIN
                billing.customer_services       cs
            ON  chrg.cs_key_num = cs.key_num
    INNER JOIN
                billing.billers                 bil
            ON  ft_cdi.biller_account_key_num = bil.biller_account_key_num
    INNER JOIN
                billing.formal_entities         fe
            ON  bil.frml_key_num = fe.key_num
WHERE
    -- ... and in the WHERE conditions here?
        ft_cdi.transaction_type <> 'Payment'   -- alias tells me this table is not for payments
    AND ft_cdi.status = 'Approved'
    AND ft_pmt.transaction_type =  'Payment'   -- alias tells me this table is for payments
    AND ft_pmt.status = 'Approved'
    AND ft_cdi.last_user_date >   ft_last_user_date_begin
    AND ft_cdi.last_user_date <=  ft_last_user_date_end
;

Acho que o uso de aliases ajuda na legibilidade de uma consulta se os nomes das tabelas forem longos ou tão semelhantes entre si que alguém que os leia rapidamente possa confundi-los. Você acha que isso...

SELECT Really_long_table_name.ID,
       Even_longer_table_name_than_before.Name,
       Even_longer_table_name_than_before.Description,
       Even_longer_table_name_than_before.State
FROM   Really_long_table_name
       INNER JOIN Even_longer_table_name_than_before
               ON Really_long_table_name.ID = Even_longer_table_name_than_before.ID
WHERE  Really_long_table_name.Department = 'Whatever' 

é mais legível do que isso?

SELECT a.ID,
       b.Name,
       b.Description,
       b.State
FROM   Really_long_table_name a
       INNER JOIN Even_longer_table_name_than_before b
               ON a.ID = b.ID
WHERE  a.Department = 'Whatever' 

Dependendo do que você usa como aliases de tabela, pode tornar a consulta muito mais simples para uma pessoa ler e entender.

O aliasing de tabela (por causa de nomes de tabela mais curtos) não é uma prática ruim.

Eu normalmente uso quando os nomes das tabelas são longos e só uso o alias que faz sentido:

SELECT tTable.stuff FROM track_table tTable;

Se você deseja melhorar a legibilidade, pode usar a ASpalavra-chave:

SELECT tTable.stuff FROM track_table AS tTable;

Mas, conforme você se acostuma com a sintaxe, ela não é necessária.

Esta é uma pergunta sobre "prática ruim". As respostas parecem ser sobre "Salvar pressionamentos de tecla".

Pessoalmente, minha velocidade de codificação é limitada pela velocidade do meu pensamento, não pela velocidade da minha digitação. Eu acho o código com muitos aliases de tabela muito mais difícil de ler do que o código que usa os próprios nomes de tabela. Os aliases de tabela adicionam outro nível de indireção.

No entanto, a maioria dos programadores usa aliases de tabela (embora eu não). Alguns "ambientes de desenvolvimento SQL" tornam isso muito fácil de fazer, e alguns professores ensinam aliases de tabelas automaticamente, especialmente como parte do aprendizado da sintaxe "Join".

Usar aliases de tabela não é uma prática ruim, mas às vezes tenho que passar pelo código e substituir os aliases pelos nomes originais da tabela para entender o que está acontecendo.

Você pode usar isso para aumentar significativamente a legibilidade de suas consultas. Em vez de usar um alias curto, use seu alias para descrever os dados aos quais você está unindo, por exemplo

SELECT
    transaction.unique_id,
    authorisingUser.name AS authorising_user_name,
    requestingUser.name AS requesting_user_name
FROM transactions AS transaction
JOIN users AS authorisingUser
    ON authorisingUser.user_id = txn.authorising_user_id
JOIN users AS requestingUser
    ON requestingUser.user_id = txn.request_user_id

Embora o uso de aliases extremamente curtos (como aou t1) possa dificultar a leitura de uma consulta, pois você precisa encontrar o alias para pesquisar o que o alias significa, um alias bem nomeado geralmente pode tornar uma consulta mais legível do que apenas usar a tabela nomes.

Meu primeiro trabalho que exigia interação regular com SQL envolvia a migração de dezenas de milhares de linhas de consultas herdadas após dezenas de colunas e tabelas terem sido movidas e renomeadas. Este processo levou anos . Esse processo poderia ter levado no máximo alguns dias se ninguém usasse aliases de tabela (ou pelo menos os evitasse quando fossem desnecessários).

Como?

Considere a seguinte consulta.

select 
employeeid,
a.cust,
b.date,
c.first_name,
c.last_name
on employee as a
inner join customers as b
using(transactionid)
left join transactions c
on c.transactionid = b.transactionid

Não pense muito sobre isso. Eu o inventei e o que ele faz não é importante. Imagine que você foi informado transactions.first_namee transactions.last_namese mudou para transactions_table.firstnamee, transactions_table.lastnamerespectivamente. Enquanto isso, transactions_tableé indexado em transaction_datetime_idvez de transactionid. Claro, você poderia gastar alguns minutos retrocedendo nessa nova consulta e trocando transactionspor transactions_table, a junção envolvendo c.transactionidpor c.transaction_datetime_id, e finalmente por firstnamee lastnamepor first_namee last_namerespectivamente.

Agora considere a seguinte consulta.

select 
employee.employeeid,
employee.cust,
customers.date,
transactions.first_name,
transactions.last_name
on employee
inner join customers
on employee.transactionid = customers.transactionid
left join transactions
on transactions.transactionid = customers.transactionid

Agora imagine fazer as mesmas mudanças. Deve ficar imediatamente claro que você pode apenas executar algumas substituições baseadas em expressões regulares cegas na consulta.

• transactions.transactionsid=>transactions_table.transaction_datetime_id
• transactions.first_name=>transactions_table.firstname
• transactions.last_name=>transactions_table.lastname
• (?<![A-Za-z0-9.])transactions(?![A-Za-z0-9])=>transactions_table

Não sou a primeira pessoa a encontrar esse problema e não serei a última (o grupo que conheci em uma empresa da qual participei posteriormente passou pelo mesmo processo meticuloso).

Se você quiser me culpar por ser novo em SQL pesado na época, observe que meu predecessor era um veterano de SQL em tempo integral por 4 anos e era a mesma pessoa que escreveu essas consultas que precisavam ser atualizadas. Ele já estava há um ano no processo de migração quando saiu e eu assumi. Recursos enormes são desperdiçados por causa de aliases de tabela desnecessários. Seriamente.