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

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

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

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

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

select person.FirstName
      ,person.LastName
      ,addr.StreetAddress
      ,addr.City
      ,addr.State
      ,addr.Zip
      ,phone.PhoneNumber
      ,company.CompanyName
from tblPeople person
left outer join tblAffiliations affl on affl.personID = person.personID
left outer join tblCompany company on company.companyID = affl.companyID

...

и т.д.

Неужели я здесь единственный человек, который действительно их ненавидит?

Как правило, я не использую их без крайней необходимости. Я просто очень ненавижу читать что-то вроде этого

select a.id, a.region, a.firstname, a.blah, b.yadda, b.huminahumina, c.crap
from table toys as a
inner join prices as b on a.blah = b.yadda
inner join customers as c on c.crap = something else
etc

Когда я читаю SQL, мне нравится точно знать, что я выбираю, когда я читаю его; псевдонимы на самом деле смущают меня больше, потому что мне приходится пробираться через строки столбцов, прежде чем я действительно доберусь до имени таблицы, которое обычно представляет информацию о данных, которых нет у псевдонима. Возможно, это нормально, если вы сделали псевдонимы, но я обычно читаю вопросы на StackOverflow с кодом, который, кажется, использует псевдонимы без уважительной причины. (Кроме того, иногда кто-то создает псевдоним в инструкции и просто не использует его. Почему?)

Я думаю, что псевдонимы таблиц используются так часто, потому что многие люди не любят печатать. Хотя я не думаю, что это хорошее оправдание. Это оправдание является причиной того, что мы в конечном итоге получаем ужасные имена переменных, ужасные акронимы функций, плохие code...I потребуют времени, чтобы ввести полное имя. Хотя я быстро печатаю, так что, возможно, это как-то связано с этим. (Возможно, в будущем, когда у меня будет кистевой туннель, я пересмотрю свое мнение о псевдонимах. :P) я особенно ненавижу перебегать через табличные псевдонимы в коде PHP, где, по моему мнению, нет абсолютно никакой причины делать это - вам нужно только ввести его один раз!

Я всегда использую квалификаторы столбцов в своих заявлениях, но я не прочь печатать много, поэтому я с удовольствием наберу полное имя несколько раз. (Конечно, я злоупотребляю завершением табуляции MySQL.) Если это не ситуация, когда мне приходится использовать псевдоним (как некоторые описанные в других ответах), я нахожу дополнительный слой абстракции громоздким и ненужным.

Edit: (более года спустя) я имею дело с некоторыми хранимыми процедурами, которые используют псевдонимы (я их не писал, и я новичок в этом проекте), и они довольно болезненны. Я понимаю, что причина, по которой я не люблю псевдонимы, заключается в том, как они определены. Вы знаете, как обычно рекомендуется объявлять переменные в верхней части области видимости? (И обычно в начале строки?) Псевдонимы в SQL не соответствуют этой конвенции, что заставляет меня скрипеть зубами. Таким образом, мне приходится искать весь код в поисках одного псевдонима, чтобы узнать, где он находится (и что самое неприятное, я должен прочитать всю логику, прежде чем найти объявление псевдонима). Если бы не это, мне, честно говоря, эта система понравилась бы больше.

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

Оптимизатор запросов Microsoft SQL выигрывает от использования либо полных имен, либо псевдонимов.

Лично я предпочитаю псевдонимы, и если у меня нет большого количества таблиц, они обычно бывают однобуквенными.

--seems pretty readable to me ;-)
select a.Text
from Question q
    inner join Answer a
        on a.QuestionId = q.QuestionId

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

Хорошо

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

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

Я полагаю, что единственное, что действительно говорит против них, - это чрезмерная абстракция. Если вы будете иметь хорошее представление о том, что означает псевдоним (хорошее именование помогает; 'a', 'b', 'c' могут быть довольно проблематичными, особенно когда вы читаете заявление месяцами или годами позже), я не вижу ничего плохого в псевдонимировании.

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

Если я сам пишу запрос (вводя его в редакторе, а не используя конструктор), я всегда использую псевдонимы для имени таблицы, поэтому мне нужно только один раз ввести полное имя таблицы.

Я действительно ненавижу читать запросы, созданные дизайнером с полным именем таблицы в качестве префикса к каждому имени столбца.

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

Они нужны вам, если вы собираетесь присоединить таблицу к себе, или если вы снова используете столбец в подзапросе...

Псевдонимы хороши, если вы считаете, что у моей организации есть имена таблиц, такие как: SchemaName.DataPointName_SubPoint_Sub-SubPoint_Sub-суб-SubPoint... Моя команда использует довольно стандартный набор сокращений, так что догадки сводятся к минимуму. Мы должны будем сказать ProgramInformationDataPoint сокращен до подп, и доводы просто суб.

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

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

ИМХО, это действительно не имеет значения с короткими именами таблиц, которые имеют смысл, я иногда работал с базами данных, где имя таблицы может быть чем-то вроде VWRECOFLY или какой-то другой случайной строки (продиктованной политикой компании), которая действительно представляет пользователей, поэтому в этом случае я нахожу псевдонимы действительно помогают сделать код FAR более читаемым. (users.username делает намного больше смысла, чем VWRECOFLY.username)

Мне нравятся длинные явные имена таблиц (обычно их количество превышает 100 символов), потому что я использую много таблиц, и если имена не являются явными, я могу запутаться в том, что хранится в каждой таблице.

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

Я всегда использую псевдонимы при написании запросов. Обычно я стараюсь сократить название таблицы до 1 или 2 репрезентативных букв. Таким образом, пользователи становятся u, а debtor_transactions - dt и т. д...

Это экономит на наборе текста и все еще несет в себе некоторый смысл.

Более короткие имена делают его более читаемым и для меня.

Я всегда использую псевдонимы, так как для получения надлежащей производительности на MSSQL вам нужно всегда иметь префикс со схемой. Так что вы увидите очень много

Выбрать Person.Name От
dbo.Person Как Человек

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

SELECT Description -- actually in a
 FROM
 table_a a,
 table_b b
 WHERE
 a.ID = b.ID

Что происходит, когда вы делаете такую мелочь, как добавление столбца под названием Description в Table_B. Добавление столбца не должно ничего нарушать. Я никогда не рассматриваю написание хорошего кода, кода без ошибок, как необходимое зло.

Псевдонимы необходимы при соединении таблиц со столбцами, имеющими одинаковые имена.