테이블 앨리어싱이 나쁜 습관입니까?

나는 정보 서비스 석사 학생들을위한 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 개발 환경"을 사용하면이 작업을 매우 쉽게 수행 할 수 있으며 일부 교사는 특히 "조인"구문 학습의 일부로 테이블 별칭을 자동으로 가르칩니다.

테이블 별칭을 사용하는 것은 좋지 않지만 때로는 상황을 이해하기 위해 코드를 살펴보고 별칭을 원래 테이블 이름으로 바꿔야합니다.