Czy aliasing stołu jest złą praktyką?

Pamiętam, że uczyłem się tego na kursie DBMS dla studentów Master of Information Services. Aby zaoszczędzić trochę pisania, możesz wpisać:

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

Ale ... Dlaczego jest to dopuszczalne w procedurach przechowywanych i tak dalej? Wygląda na to, że wszystko, co robi, szkodzi czytelności instrukcji, a jednocześnie oszczędza bardzo mało czasu. Czy istnieje jakiś funkcjonalny lub logiczny powód, aby to zrobić? Wydaje się, że dodaje niejasności, a nie ją usuwa; jedynym dopuszczalnym powodem, dla którego widzę użycie tego formatu, jest dodanie aliasu znaczącego semantycznie - na przykład FROM someTable idsTable- gdy nazwa tabeli nie jest wystarczająco opisowa.

Czy aliasing stołu jest złą praktyką, czy to tylko niewłaściwe użycie pomocnego systemu?

Alias ​​tabel jest powszechną i pomocną praktyką.

• Oszczędza to naciśnięć klawiszy podczas odwoływania się do kolumn w dowolnym miejscu zapytania.
• Poprawia to czytelność kodu SQL podczas odwoływania się do wielu tabel. Aliasy pozwalają ci nadać tym tabelom krótką nazwę i trochę znaczenia, w jaki sposób są używane.
• Jest to nawet wymagane, jeśli dołączasz do stołu do siebie lub gdy dołączasz do tego samego stołu wiele razy. Dzięki temu optymalizator zapytań wie, do której tabeli się odwołujesz, gdy wspominasz o kolumnie.

Poniższy fragment raportu ładnie ilustruje wszystkie powyższe punkty:

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
;

Myślę, że użycie aliasów poprawia czytelność zapytania, jeśli nazwy tabel są długie lub tak do siebie podobne, że ktoś, kto je szybko przeczyta, może je pomylić. Czy uważasz, że to ...

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' 

jest bardziej czytelny niż to?

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' 

W zależności od tego, czego używasz jako aliasy tabeli, może to znacznie ułatwić kwerendę dla osoby czytającej i rozumiejącej.

Aliasing tabel (ze względu na krótsze nazwy tabel) nie jest złą praktyką.

Zwykle używam go, gdy nazwy tabel są długie, a następnie używam tylko aliasu, który ma sens:

SELECT tTable.stuff FROM track_table tTable;

Jeśli chcesz poprawić czytelność, możesz użyć ASsłowa kluczowego:

SELECT tTable.stuff FROM track_table AS tTable;

Ale kiedy przyzwyczaisz się do składni, nie jest to konieczne.

Możesz użyć tego, aby znacznie zwiększyć czytelność swoich zapytań. Zamiast używać krótkiego aliasu, użyj swojego aliasu, aby na przykład opisać dane, do których dołączasz

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

Chociaż użycie wyjątkowo krótkich aliasów (takich jak alub t1) może utrudnić odczytanie zapytania, ponieważ musisz znaleźć i znaleźć alias, aby sprawdzić, co oznacza alias, dobrze nazwany alias może często sprawić, że zapytanie będzie bardziej czytelne niż użycie tabeli nazwy.

To pytanie dotyczy „złej praktyki”. Wydaje się, że odpowiedzi dotyczą „Zapisywania naciśnięć klawiszy”.

Osobiście moja szybkość kodowania jest ograniczona szybkością myślenia, a nie szybkością pisania. Uważam, że kod z dużą ilością aliasów tabel jest znacznie trudniejszy do odczytania niż kod, który używa samych nazw tabel. Aliasy tabel dodają kolejny poziom pośredni.

Jednak większość programistów używa aliasów tabel (chociaż ja nie). Niektóre „środowiska programistyczne SQL” sprawiają, że jest to bardzo łatwe, a niektórzy nauczyciele uczą aliasy tabel automatycznie, szczególnie w ramach uczenia się składni „Dołącz”.

Używanie aliasów tabel nie jest złą praktyką, ale czasami muszę przejść przez kod i zastąpić aliasy oryginalnymi nazwami tabel, aby zrozumieć, co się dzieje.