テーブルのエイリアシングは悪い習慣ですか?


21

マスターオブインフォメーションサービスの学生向けのDBMSコースでこれを学習したことを覚えています。入力を節約するために、次のように入力できます。

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

しかし...ストアドプロシージャなどでこれが受け入れられるのはなぜですか?非常に短い時間を節約しながら、ステートメントの可読性を損なうだけであるようです。これを行う機能的または論理的な理由はありますか?曖昧さを削除するのではなく、追加するようです。この形式を使用するために私が見ることができる唯一の受け入れられる理由はFROM someTable idsTable、テーブル名が十分に説明的でない場合に、意味的に意味のあるエイリアスを追加していた場合です。

テーブルのエイリアシングは悪い習慣ですか、これは単に有用なシステムの誤用ですか?


8
数千行のSQLを記述した場合、保存された入力に感謝します。これは、注意して使用すると、保守性をほとんどまたはまったく犠牲にすることなく生産性を向上させることができる場合です。
すべての取引のジョン

6
1つのテーブルから始まるほとんどのクエリは、最終的にはより多くのテーブルを含むようになりました(「これは素晴らしいですが、Fooを追加できますか?」)。すべての列を前もってエイリアス化すると、生活が簡素化されます。
billinkc

すべてのクエリですべてのテーブルをエイリアスするこの非常に一般的なプラクティスについて私が見ることができる唯一の良い点は、時々創造的な開発者がコードにいたずらな単語を滑り込ませることです!
ニードハック14

どうしてselect id, stuff from someTable natural join otherTable
コリン 'ハート

回答:


39

テーブルのエイリアシングは一般的で便利な方法です。

  • クエリの任意の場所で列を参照するときにキーストロークを節約します。
  • 多くのテーブルを参照している場合、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
;

2
エイリアスは、多くのSQLを書いて読んだ人にとって読みやすいです。新しいデータベース開発者にとっては読みにくいですが、遅かれ早かれクリアしなければならないハードルだと思います。
マイクシェリル 'キャットリコール'

7
意味のあるエイリアスを心からお勧めします。t1、t2 ...またはa、b、b、c、d、e ....の代わりに意味のあるエイリアスを使用した例を見るのは本当に素晴らしいです。 、アカウントc、請求d、顧客e。
-BillThor

4
また、メンテナンスを容易にするために、すべての列参照でエイリアスを使用することも重要だと思います。確かに、1つのテーブルだけにxyzjunkという名前のフィールドがありますが、どのテーブルですか?複雑なレポートクエリを作成する場合、フィールドがどこから来たのかを常に把握しておくと役立ちます。
HLGEM

1
また、派生テーブルに結合する場合にも必要です。
HLGEM

@HLGEM-両方の優れた点。
ニックチャマス

12

エイリアスを使用すると、テーブル名が長いか類似しているため、テーブル名をすぐに読むと間違える可能性がある場合に、クエリを読みやすくすることができます。これと思いますか...

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' 

テーブルエイリアスとして使用するものに応じて、クエリを人が読みやすく理解しやすくすることができます。


2
私は常に、テーブルにエイリアスを作成しない開発者を探し出し、殺します(文字通りではありません)。その最初の例は私の目を出血させます。そして、どういうわけか、彼らがこれを行うとき、彼らはコードを作成しないので、スクロールせずにそれを見ることができます(ちょうどあなたがしたように)。
HLGEM

5

テーブルのエイリアシング(テーブル名を短くするため)は悪い習慣ではありません。

通常、テーブル名が長い場合に使用し、意味のあるエイリアスのみを使用します。

SELECT tTable.stuff FROM track_table tTable;

読みやすくする場合は、次のASキーワードを使用できます。

SELECT tTable.stuff FROM track_table AS tTable;

しかし、構文に慣れると、それは必要ありません。


0

これを使用して、クエリの可読性を大幅に高めることができます。短いエイリアスを使用するのではなく、エイリアスを使用して、参加するデータを記述します。たとえば、

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)を使用すると、エイリアスを探してエイリアスの意味を調べる必要があるため、クエリを読みにくくすることができますが、よく名前の付いたエイリアスは、テーブルを使用するよりもクエリを読みやすくすることができます名前。


-1

これは「悪い習慣」についての質問です。答えは「キーストロークの保存」に関するもののようです。

個人的には、コーディング速度はタイピング速度ではなく思考速度によって制限されます。多くのテーブルエイリアスを含むコードは、テーブル名自体を使用するコードよりも読みにくいと思います。テーブルエイリアスは、別のレベルの間接参照を追加します。

ただし、ほとんどのプログラマーはテーブルエイリアスを使用します(私は使用しませんが)。一部の「SQL開発環境」ではこれが非常に簡単になり、一部の教師は、特に「結合」構文の学習の一環として、テーブルエイリアスを自動的に教えます。

テーブルエイリアスを使用することは悪い習慣ではありませんが、何が起こっているのかを理解するために、コードを調べてエイリアスを元のテーブル名に置き換える必要がある場合があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.