主页 / dba / 问题 / 5989
Accepted
Ben Brocka
Asked: 2011-09-21 06:17:09 +0800 CST

表别名是一种不好的做法吗？

  • 772

我记得在为信息服务硕士学生开设的 DBMS 课程中学习如何做到这一点。为了节省一些输入，您可以输入：

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

但是......为什么这在存储过程等中是可以接受的？似乎它所做的只是损害了语句的可读性，同时节省了极少的时间。这样做是否有任何功能或逻辑原因？它似乎增加而不是消除歧义；我可以看到使用这种格式的唯一可接受的原因是如果您添加了一个语义上有意义的别名——例如FROM someTable idsTable——当表名描述性不够时。

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

stored-procedures best-practices

6 个回答

  1. Best Answer

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

    • 在查询中的任何位置引用列时，它可以节省您的击键次数。
    • 当您引用许多表时，它提高了 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
;
    • 41

  2. 我认为使用别名有助于查询的可读性，如果表名很长或彼此非常相似，以至于快速阅读它的人可能会弄错它们。你觉得这...

    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'

    根据您用作表别名的内容，它可以使查询更易于人们阅读和理解。

    • 13

  3. 表别名（为了缩短表名）不是坏习惯。

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

    SELECT tTable.stuff FROM track_table tTable;

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

    SELECT tTable.stuff FROM track_table AS tTable;

    但是，当您习惯了语法时，就不需要它了。

    • 5

  4. 这是一个关于“不良做法”的问题。答案似乎是关于“保存击键”。

    就个人而言，我的编码速度受限于我的思维速度，而不是我的打字速度。我发现具有大量表别名的代码比使用表名本身的代码更难阅读。表别名增加了另一层间接性。

    然而，大多数程序员确实使用表别名（尽管我没有）。一些“SQL 开发环境”使这很容易做到，一些教师自动教授表别名，特别是作为学习“Join”语法的一部分。

    使用表别名不是坏习惯，但有时我必须通过代码并用原始表名替换别名才能了解发生了什么。

    • 1

  5. 您可以使用它来显着提高查询的可读性。与其使用短别名，不如使用您的别名来描述您要加入的数据，例如

    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

    虽然使用极短的别名（如aor t1）可能会使查询难以阅读，因为您需要查找别名以查找别名的含义，但命名良好的别名通常可以使查询比仅使用表更具可读性名字。

    • 0

  6. 我的第一份需要定期与 SQL 交互的工作涉及在移动和重命名数十个列和表之后迁移数万行遗留查询。这个过程花费了数年时间。如果没有人使用表别名（或者至少在不必要时避免使用它们），这个过程最多可能需要几天时间。

    如何？

    考虑以下查询。

    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

    不要想太多。我编造的，它的作用并不重要。想象一下，您被告知transactions.first_name并transactions.last_name已分别移至transactions_table.firstname和transactions_table.lastname。同时，transactions_table被索引transaction_datetime_id而不是transactionid. 当然，您可以花几分钟回溯这个新查询并分别换出transactionsfor transactions_table、涉及c.transactionidforc.transaction_datetime_id和 finallyfirstname和lastnamefor 的first_name连接last_name。

    现在考虑以下查询。

    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

    现在想象一下做同样的改变。应该立即清楚您可以在查询上运行一些基于正则表达式的盲替换。

    • 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

    我不是第一个遇到这个问题的人，也不会是最后一个（我在后来加入的一家公司遇到的小组也经历了同样的艰苦过程）。

    如果你想责怪我当时是重 SQL 的新手，那么请注意，我的前任是一个 4 年的全职 SQL 资深人士，并且是编写这些需要更新的查询的同一个人。当他离开并由我接手时，他已经进行了一年的迁移。由于不必要的表别名而浪费了大量资源。严重地。

    • -1

相关问题