← Все курсы · Курс SQL · Все руководства

Псевдонимы SQL: как прочитать запрос вслух

что AS изменения, почему таблицам присваиваются однобуквенные псевдонимы, а также правило области действия, которое сбивает людей с толку. · Часть Analyst Prep Kit

К Майкл Носито, аналитик данных · Обновлено 29 июля 2026 г.

После этой страницы вы можете прочитать вслух любой запрос и узнать, к чему относится каждое имя в нем. Вы также будете называть вещи так, как ожидает рецензент. Именно это делает запрос похожим на работу человека, который этим зарабатывает на жизнь.

Вот что вы делаете. Дайте каждому вычисляемому столбцу имя с помощью AS. Присвойте каждой таблице однобуквенное имя, как только запрос коснется двух из них. Затем поместите этот псевдоним перед каждым столбцом, чтобы читателю никогда не приходилось догадываться, из какой таблицы взят тот или иной столбец. Три привычки, на освоение которых уходит около минуты.

Что меняет псевдоним столбца

Перед ответом: если вы напишете SELECT title AS gem FROM gem_page, есть что-нибудь в gem_page таблица изменилась?

Нет. Ничего в сохраненной таблице не перемещается. Псевдоним — это метка возвращаемого вам результата, а результат — это временная вещь, которая перестает существовать, когда вы закрываете окно. Столбец в базе данных по-прежнему называется title завтра.

Слово Псевдоним означает дополнительное имя для чего-то, что уже существует. В этом вся идея, и именно поэтому одно и то же слово обозначает столбцы и таблицы. Вот версия колонки:

SELECT title AS gem
FROM gem_page;

Результат возвращается с заголовком столбца, который читается gem вместо title. Те же значения, то же количество строк, другая метка. Если вы экспортируете этот результат в электронную таблицу, в строке заголовка таблицы будет написано: gem, потому что строка заголовка — это именно то, что установил псевдоним.

Вот и весь эффект псевдонима столбца. Он переименовывает вывод. Он не переименовывает столбец, не фильтрует, не меняет ни одного значения.

Почему безымянный вычисляемый столбец — дефект

Вычисляемый столбец — это столбец, который база данных обрабатывает на месте, а не считывает с диска. Своего имени у него нет, потому что в таблице ничего так не называется. Таким образом, база данных изобретает за вас заголовок, а то, что она изобретает, непригодно для использования.

SELECT title,
       ROUND(CAST(up AS REAL) / (up + down) * 100, 1)
FROM gem_page;

SQLite возвращает это с заголовком столбца ROUND(CAST(up AS REAL) / (up + down) * 100, 1). Заголовок — это все выражение, знаки препинания и все такое. PostgreSQL идет другим путем и идет вперед. round, после самой внешней функции. Это имя не может использовать каждый.

Это важно по трем конкретным причинам, и каждая из них проявляется в реальном отчете:

• Вы не можете сортировать по нему. ORDER BY нужно что-то, на что можно сослаться, и это не слишком пунктуационное выражение. В конечном итоге вы перепечатываете весь расчет в ORDER BY линия.
• Два расчета сталкиваются. Добавить второй ROUND к одному и тому же запросу в PostgreSQL, и у вас есть два столбца, оба заголовка round. Кто бы ни прочитал этот результат дальше, он должен угадать, что есть что.
• Экспорт не читается. Строка заголовка CSV-файла, который вы отправляете заинтересованной стороне, содержит выражение SQL. Это версия вашей работы, которую они видят.

Исправление — одно слово плюс выбранное вами имя:

SELECT title,
       ROUND(CAST(up AS REAL) / (up + down) * 100, 1) AS pct_positive
FROM gem_page
ORDER BY pct_positive DESC;

Теперь в заголовке написано pct_positive, строка сортировки относится к нему по этому имени, и передаваемая вами электронная таблица читается как написанная человеком.

Псевдонимы таблиц и двусмысленность, которую они устраняют

Перед ответом: в двух таблицах есть столбец с именем id. Вы присоединяетесь к ним и просите id. Что должна делать база данных?

Он отказывается, и это правильно. Скажем, ваши две таблицы gem_page, одна строка на каждый музыкальный камень и gem_vote, одна строка на голос читателя. Оба содержат столбец с именем id. Этот запрос не имеет ответа:

SELECT id, title
FROM gem_page
JOIN gem_vote ON gem_page.id = gem_vote.page_id;

Error: ambiguous column name: id

Неоднозначность означает, что база данных нашла имя более чем в одном месте и не выберет его за вас. Чтобы ответить на этот вопрос, нужно сказать, какую таблицу вы имели в виду, поместив имя таблицы перед столбцом с точкой между ними. Это префикс.

SELECT gem_page.id, gem_page.title
FROM gem_page
JOIN gem_vote ON gem_page.id = gem_vote.page_id;

Это работает, и это быстро растягивается. Псевдоним таблицы — это короткое прозвище, которое вы даете таблице один раз, в тот момент, когда вы ее называете, а затем используете везде:

SELECT g.id, g.title, v.voter
FROM gem_page AS g
JOIN gem_vote AS v ON g.id = v.page_id;

FROM gem_page AS g говорит: для остальной части этого запроса, g означает gem_page стол. С этого момента g.title это заголовок столбца gem_page, и v.voter это столбец избирателей gem_vote. Две буквы заменили двадцать.

Прежде чем читать дальше, скажите, почему это стоит сделать. Речь не идет о том, чтобы меньше печатать. Причина в том, что теперь читатель может ответить: «Из какой таблицы этот столбец?» для каждого столбца запроса, без прокрутки и без знания схемы. В запросе из трех таблиц этот вопрос возникает в каждой строке.

Правило области действия: ORDER BY да, WHERE нет

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

SELECT title,
       up + down AS total_votes
FROM gem_page
WHERE total_votes > 10;

ERROR:  column "total_votes" does not exist

Имя тут же, в четыре строки вверх. PostgreSQL говорит, что его не существует. MySQL говорит Unknown column 'total_votes' in 'where clause'. Оба говорят вам правду, и причина в порядке.

База данных не выполняет запрос сверху вниз так, как вы его читаете. Он выполняет положения в своем собственном фиксированном порядке и SELECT приходит с опозданием в таком порядке:

Таким образом, правило выпадает само по себе. WHERE бежит раньше SELECT, поэтому при применении фильтра имя total_votes еще не изобретено. ORDER BY бежит за SELECT, поэтому к тому времени имя уже существует, и вы можете сортировать по нему:

SELECT title,
       up + down AS total_votes
FROM gem_page
WHERE up + down > 10
ORDER BY total_votes DESC;

в WHERE вы повторяете расчет. В ORDER BY вы используете имя. Эти же рассуждения охватывают GROUP BY и HAVING, которые также выполняются перед SELECT, поэтому повторите выражение и там, и вы будете правы в каждой базе данных.

Как читать каждую фигуру вслух

Чтение запроса вслух — это самый быстрый способ узнать, действительно ли вы ему следуете. Это буквальные предложения. Произнесите их точно, включая скучные части.

Два из этих предложений делают свое дело. «который я буду называть г для оставшейся части этого запроса» — это тот, который заставляет псевдоним таблицы перестать быть загадочным. «Колонка художника на странице драгоценный камень_страница» — это та, которая превращает точку в повседневную речь.

А теперь представьте, что вы запускаете это на своем собственном столе, который вы уже открыли. Произнесите вслух два предложения, соответствующие его названию и одному из его столбцов. Как выглядит строка заголовка результата?

SELECT g.artist,
       COUNT(v.id) AS vote_count,
       ROUND(AVG(v.score), 1) AS avg_score
FROM gem_page AS g
JOIN gem_vote AS v ON g.id = v.page_id
GROUP BY g.artist
ORDER BY avg_score DESC;

Вслух, от начала до конца: выберите столбец Художник на странице драгоценный камень_страница, количество строк идентификаторов драгоценный камень_голосование, называемое voice_count, и средний балл, округленный до одного десятичного знака, называемый avg_score. Из таблицы драгоценный камень_страница, которую я назову г. Добавьте драгоценный камень_голосование, назовите его в, сопоставив, где идентификатор г равен page_id v. Группировка по столбцу художника на странице драгоценный камень_страница. Сортировка по столбцу, который я назвал avg_score, сначала по величине.

Это приговор. Ничто в нем не мешает синтаксическому анализу, и ничто из этого не требует от вас предварительного знания схемы.

Когда использовать псевдоним, а когда оставить имя в покое

Псевдоним всего - это своего рода нечитабельность. Четыре рабочих правила охватывают почти каждый запрос, который вы напишете.

AS не является обязательным, и вам все равно следует его ввести.

Каждый пример на этой странице работает без слова AS. Эти две строки делают одно и то же, как и эти две:

SELECT title AS gem FROM gem_page AS g;
SELECT title    gem FROM gem_page    g;

Второй стиль вы будете встречать постоянно, потому что уходит много производственного SQL. AS вне. Прочитайте это так, как если бы это слово было там. В любом случае напечатайте это по причине, не связанной со стилем.

Уход AS вне делает одну ошибку невидимой. Поставьте запятую в SELECT список, и два столбца молча становятся одним столбцом с псевдонимом:

SELECT title, artist year
FROM gem_page;

Вы имели в виду три столбца. Вы получаете два: titleи artist столбец с надписью year. Никакой ошибки и заголовок, который читает year выше текстовых значений. С AS в ваших привычках пропущенная запятая с первого взгляда читается неправильно. Это тот же класс отказов, что и соединения, которые удалить или дублировать строки без ошибок, и его перехватывают таким же образом, делая намерение явным.

Одно место AS не является обязательным: иногда оно требуется для именования таблицы в PostgreSQL, а имя, которое в противном случае было бы прочитано как ключевое слово, всегда требуется. Если набирать его каждый раз, вопрос снимается.

Полное до и после

Те же таблицы, тот же вопрос, обе версии работают. Разница в том, сможет ли человек прочитать результат.

До

SELECT gem_page.artist,
       COUNT(gem_vote.id),
       ROUND(AVG(gem_vote.score), 1)
FROM gem_page
JOIN gem_vote ON gem_page.id = gem_vote.page_id
GROUP BY gem_page.artist
ORDER BY ROUND(AVG(gem_vote.score), 1) DESC;

Два из трех столбцов возвращаются с заголовками, которые никто не может использовать, поэтому ORDER BY придется повторить весь расчет. Каждая строка содержит полное имя таблицы. Запрос правильный и утомительный.

после

SELECT g.artist,
       COUNT(v.id) AS vote_count,
       ROUND(AVG(v.score), 1) AS avg_score
FROM gem_page AS g
JOIN gem_vote AS v ON g.id = v.page_id
GROUP BY g.artist
HAVING COUNT(v.id) >= 10
ORDER BY avg_score DESC;

Три именованных столбца, две таблицы с именами и строка сортировки, которая ссылается на имя, а не повторяет вычисление. Обратите внимание, что HAVING все еще пишется COUNT(v.id), потому что HAVING бежит раньше SELECT и имени еще не существует. Блок комментариев, расположенный над таким запросом, находится в Как комментировать SQL, чтобы он обучал.

Откуда это взялось и почему это работает

Идея старше SQL. В реляционной модели, на которой построены базы данных, переименование является одной из основных операций, которые вы можете выполнять с таблицей. Он находится рядом с выбором строк и столбцов (Кодд, 1970, Коммуникации ACM, 13(6), 377–387). Возможность дать чему-то второе имя — это часть теории, а не удобство, к которому кто-то прикрутил позже.

Конкретный синтаксис взят из SEQUEL, языка, созданного IBM в 1974 году и ставшего впоследствии SQL. Дональд Чемберлин и Рэймонд Бойс разработали его так, чтобы его могли читать люди, не являющиеся программистами. Застольное прозвище было в первой статье (Чемберлин и Бойс, 1974, Материалы семинара ACM SIGFIDET 1974 г., 249–264). Они назвали это имя корреляции, и вы до сих пор увидите эту фразу в документации по базе данных. Это означает именно то, что на этой странице называется псевдонимом таблицы.

Причина, по которой именование помогает читателю лучше понять, чем раньше. Учащиеся, которые объясняют себе проработанный пример по ходу дела, понимают его значительно лучше. Они также передают его лучше, чем учащиеся, которые читают тот же пример, не объясняя его (Чи, Басок, Льюис, Рейманн & Глейзер, 1989, Когнитивная наука, 13(2), 145–182). Запрос, полный именованных столбцов и таблиц с префиксами, — это запрос, который вы можете объяснить себе во время чтения. Один без них заставляет вас одновременно удерживать схему в голове, что является рабочей памятью, необходимой вам для реального вопроса.

Именно поэтому фраза «Я знаю, что означают мои собственные колонки» — не повод пропускать имена. Читатель, у которого не хватает рабочей памяти, — это вы через шесть месяцев открываете файл, который не помните, как писали.

Использование этого в ваших собственных запросах

Вспомните вопрос, который вы уже написали и которым поделились. Можете ли вы сказать вслух, как называется каждый из его выходных столбцов и почему? Если заголовок на нем читается round или COUNT(*), это то, что нужно исправить в первую очередь.

Проходить весь проект за один присест – это ужасно, и вы остановитесь на полпути. Вместо этого сделайте это по порядку:

1. Назовите каждый вычисляемый столбец в файле, который вы сейчас открыли. Искать ROUND, SUM, COUNT и AVG, и проверьте, что у каждого из них есть AS после этого. Это десять минут и это большая часть пользы.
2. Присвойте таблицам псевдонимы в любом запросе, касающемся двух из них. Первая буква каждой таблицы, префикс в каждом столбце. Выполняйте только запросы к нескольким таблицам. Запросы к одной таблице уже подходят.
3. Прочитайте один вопрос вслух, используя предложения из таблицы выше. Строка, в которой вы колеблетесь, — это линия, имена которой не имеют никакого значения.
4. Перенести расчеты из ORDER BY. В любом месте строка сортировки повторяет выражение из SELECT, замените его псевдонимом. Запрос стал короче, и теперь есть одно место для изменения вычислений вместо двух.
5. Оставьте простые столбцы в покое. Не поддавайтесь желанию переименовать artist к artist_name пока ты там. Переименование само по себе — это работа, из-за которой файл сложнее отследить.

Если у вас под рукой есть бумага, стоит один раз нарисовать эту. Напишите запрос, затем нарисуйте стрелку от каждого псевдонима к объекту, который он называет. Стрелки, которые трудно нарисовать, — это имена, которые не тянут своего веса.

Шпаргалка

И последнее, и мне хотелось бы услышать ответы других людей. Недавно я приобрел привычку добавлять префиксы к столбцам, которые еще не были двусмысленными, потому что это казалось беспорядком, пока не прибыла третья таблица и не доказала, что это не так. Какой привычке давать имена вы сопротивлялись дольше всего, прежде чем она завоевала свое место?

Ссылки

• Кодд, EF (1970). Реляционная модель данных для крупных общих банков данных. Коммуникации ACM, 13(6), 377–387.
• Чемберлин Д.Д. и Бойс Р.Ф. (1974). ПРОДОЛЖЕНИЕ: структурированный английский язык запросов. Материалы семинара ACM SIGFIDET 1974 г. по описанию данных, доступу и контролю., 249–264.
• Чи, М.Т.Х., Бассок, М., Льюис, М.В., Рейманн, П. и Глейзер, Р. (1989). Самообъяснения: как учащиеся изучают и используют примеры при обучении решению проблем. Когнитивная наука, 13(2), 145–182.