Чи збиток таблиці - це погана практика?

Я пам’ятаю, як навчився це робити в курсі СУБД для студентів магістрів інформаційних служб. Щоб заощадити себе на друку, можна ввести:

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" роблять це дуже просто, а деякі вчителі автоматично навчають псевдоніми таблиць, особливо в рамках вивчення синтаксису "Приєднатися".

Використання псевдонімів таблиці не є поганою практикою, але іноді мені доводиться пройти код і замінити псевдоніми оригінальні назви таблиць, щоб зрозуміти, що відбувається.