Псевдонимы таблиц SQL - хорошо или плохо?

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

Ответов (17)

Решение

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

... так далее

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

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

Выберите Person.Name From
dbo.Person as Person

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это экономит время на вводе текста и по-прежнему несет в себе какой-то смысл.

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

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

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

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

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

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

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

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

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

Хороший

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

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

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

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

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 с кодом, который, кажется, использует псевдонимы без уважительной причины. (Кроме того, иногда кто-то создает псевдоним в заявлении и просто не использует его. Почему?)

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

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

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

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