Ответ 1

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

... и т.д.

Ответ 2

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

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

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

Ответ 3

Я единственный человек, который действительно их ненавидит?

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

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

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

Ответ 4

Оптимизатор запросов Microsoft SQL имеет преимущества от использования либо полностью квалифицированных имен, либо псевдонимов.

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

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

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

Ответ 5

Хорошо

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

Ответ 14

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

Выбрать   Person.Name От
  dbo.Person As Person

Ответ 15

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

Это экономит при наборе текста и все еще имеет какое-то значение.

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

Ответ 16

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

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

Что происходит, когда вы делаете что-то вроде добавления столбца "Описание в таблицу_B". Правильно, вы получите сообщение об ошибке. Добавление столбца не требует ничего. Я никогда не вижу написания хорошего кода, кода без ошибок, как необходимого зла.

Ответ 17

Псевдонимы требуются при объединении таблиц с столбцами, имеющими идентичные имена.