表别名是不好的做法吗？

我记得在DBMS课程中为信息服务硕士课程的学生学习过这一点。为了节省输入时间，您可以输入：

SELECT t1.id, t2.stuff 
FROM 
              someTable    t1 
   INNER JOIN otherTable   t2 
      ON t1.id=t2.id
;

但是...为什么在存储过程之类中可以接受？似乎这样做只会损害语句的可读性，同时又节省了很少的时间。有任何功能或逻辑上的理由要这样做吗？似乎增加了歧义而不是消除了歧义。我看到使用这种格式的唯一可以接受的原因是，如果要添加一个语义上有意义的别名（例如，FROM someTable idsTable当表名的描述性不足时）。

表别名是不好的做法还是只是滥用有用的系统？

表别名是一种常见且有用的做法。

• 引用查询中任何地方的列时，可以节省击键操作。
• 当您引用许多表时，它可以提高SQL的可读性。别名使您可以为这些表起一个简短的名字，以及对其使用方式的一点含义。
• 当您将一个表连接到自身或多次连接到同一张表时，甚至是必需的。这样，查询优化器在提及列时就知道要引用的表。

以下报告摘录很好地说明了上述所有要点：

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
;

我认为如果表名太长或彼此相似，以至于有人快速阅读该表名可能会误认为它们，则使用别名有助于提高查询的可读性。你认为这个...

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' 

比这更具可读性？

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' 

根据您用作表别名的方式，它可以使查询变得更容易使人阅读和理解。

表别名（为了缩短表名）不是一个坏习惯。

我通常在表名很长时使用它，然后仅使用有意义的别名：

SELECT tTable.stuff FROM track_table tTable;

如果要提高可读性，可以使用AS关键字：

SELECT tTable.stuff FROM track_table AS tTable;

但是，由于您习惯了语法，因此不需要它。

您可以使用它来大大提高查询的可读性。例如，不要使用简短的别名，而使用别名来描述您要加入的数据。

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

尽管使用极短的别名（如a或t1）会使查询变得难以阅读，因为您需要去查找别名来查找别名的含义，而命名良好的别名通常会使查询比仅使用表更具可读性名称。

这是关于“不良做法”的问题。答案似乎与“节省键击”有关。

就个人而言，我的编码速度受我的思考速度限制，而不是受我的打字速度限制。我发现具有很多表别名的代码比使用表名本身的代码难读。表别名添加了另一个间接级别。

但是，大多数程序员确实使用表别名（尽管我没有）。一些“ SQL开发环境”使此操作变得非常容易，并且一些教师会自动教表别名，尤其是在学习“ Join”语法的过程中。

使用表别名不是一个坏习惯，但是有时我必须遍历代码并用原始表名替换别名，以了解正在发生的情况。