Является ли псевдоним таблицы плохой практикой?


21

Я помню, как учился делать это в курсе СУБД для студентов магистра информационных услуг. Чтобы сэкономить время при наборе текста, вы можете набрать:

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

Но ... Почему это допустимо в хранимых процедурах и тому подобное? Кажется, что все, что он делает, - это ухудшает читабельность заявления, экономя при этом крайне незначительное количество времени. Есть ли функциональная или логическая причина для этого? Кажется, что он добавляет двусмысленность, а не убирает ее; единственная приемлемая причина, которую я вижу для использования этого формата, заключается в том, что вы добавляете семантически значимый псевдоним - например, FROM someTable idsTable- когда имя таблицы недостаточно наглядно .

Является ли использование псевдонимов таблиц плохой практикой или это просто злоупотребление полезной системой?


8
Когда вы написали несколько тысяч строк SQL, вы оцените сохраненную типизацию. Это тот случай, когда при осторожном использовании вы можете купить повышенную производительность за небольшую плату или без затрат на ремонтопригодность.
Джон на все руки

6
Большинство написанных мною запросов, которые начинались с одной таблицы, в конечном итоге росли, охватывая больше таблиц («Это здорово, но можете ли вы добавить Foo?»). Псевдоним каждой колонки заранее упростит вашу жизнь.
billinkc

Единственная хорошая вещь, которую я вижу в этой очень распространенной практике совмещения имен всех таблиц во всех запросах, - это то, что иногда креативному разработчику удается вставить непослушное слово в код!
NeedHack

Почему не просто select id, stuff from someTable natural join otherTable?
Colin 't Hart

Ответы:


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. Они менее читабельны для разработчиков новых баз данных, но я думаю, что это препятствие, которое они должны рано или поздно устранять.
Майк Шеррилл 'Cat Recall'

7
Я искренне рекомендую значимые псевдонимы. Очень приятно видеть пример со значимыми псевдонимами вместо t1, t2 ... или a, b, b, c, d, e .... Это может сбить с толку, когда вы получаете псевдонимы, такие как сотрудники a, адреса b , счета c, выставление счетов d, клиенты e.
BillThor

4
Я думаю, что также важно использовать псевдоним для каждой ссылки на столбец, чтобы упростить поддержку. Конечно, только одна таблица имеет поле с именем 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» делают это очень простым, а некоторые учителя автоматически обучают псевдонимам таблиц, особенно в рамках изучения синтаксиса «Присоединения».

Использование псевдонимов таблиц не является плохой практикой, но иногда мне приходится проходить через код и заменять псевдонимы исходными именами таблиц, чтобы понять, что происходит.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.