Когда использовать псевдоним таблицы SQL

Мне любопытно узнать, как люди используют псевдонимы таблиц. Другие разработчики, в которых я работаю, всегда используют псевдонимы таблиц и всегда используют псевдоним a, b, c и т.д.

Вот пример:

SELECT a.TripNum, b.SegmentNum, b.StopNum, b.ArrivalTime
FROM Trip a, Segment b
WHERE a.TripNum = b.TripNum

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

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

Я также считаю, что псевдоним должен быть описательным именем, а не просто буквой. В приведенном выше примере, если бы я чувствовал, что мне нужно использовать 1 псевдоним таблицы, я бы использовал t для таблицы Trip и s для таблицы сегментов.

ОТВЕТЫ

Ответ 1

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

SELECT t.TripNum, s.SegmentNum, s.StopNum, s.ArrivalTime 
FROM Trip t, Segment s 
WHERE t.TripNum = s.TripNum

Это просто упрощает чтение для меня.

Ответ 2

Существует две причины использования псевдонимов таблиц.

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

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

Два примера: таблица сотрудников, содержащая столбец supervisorID, который ссылается на идентификатор employeeID супервизора.

Второй - взрыв деталей. Часто это выполняется в отдельной таблице с тремя столбцами: ComponentPartID, AssemblyPartID и Quantity. В этом случае не будет никаких самостоятельных соединений, но между этой таблицей и двумя различными ссылками на таблицу частей часто будет трехстороннее соединение.

Хорошая привычка.

Ответ 3

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

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

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

Используя текущий пример, я бы сделал что-то вроде:

SELECT TripNum, TripSegment.SegmentNum, TripSegment.StopNum, TripSegment.ArrivalTime 
FROM Trip, Segment TripSegment 
WHERE TripNum = TripSegment.TripNum

Ответ 4

Могу ли я добавить к дискуссии, которая уже несколько лет?

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

Ответ 5

Я использую его всегда, причины:

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

Рассмотрим следующий пример:

select col1, col2
from tab1
join tab2 on tab1.col3 = tab2.col3

Теперь, представьте себе несколько месяцев спустя, вы решили добавить столбец с именем 'col1' в tab2. База данных будет тихо позволять вам это делать, но приложения будут ломаться при выполнении вышеуказанного запроса из-за неоднозначности между tab1.col1 и tab2.col1.

Но, я согласен с вами в именовании: a, b, c отлично, но t и s будет намного лучше в вашем примере. И когда у меня одна и та же таблица более одного раза, я бы использовал t1, t2,... или s1, s2, s3...

Ответ 6

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

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

поэтому вместо, например:

SELECT SUM(a.VALUE) 
       FROM Domesticvalues a, Foreignvalues b 
       WHERE a.Value>b.Value
       AND a.Something ...

Пишу:

select SUM(DVAL.Value) 
       from DomesticValues DVAL, ForeignValues FVAL 
       where DVAL.Value > FVAL.Value
       and   DVAL.Something ...

Ответ 7

Я считаю, что вы должны использовать их как можно чаще, но я согласен, что t и s представляют сущности лучше, чем a и b.

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

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

Ответ 8

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

select PartNumber, I.InventoryTypeId, InventoryTypeDescription
from dbo.Inventory I
    inner join dbo.InventoryType IT on IT.InventoryTypeId = I.InventoryTypeId

В приведенном выше примере обе таблицы имеют поле InventoryTypeId, но другие имена полей уникальны.

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

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

select *
from (
    select field1, field2, sum(field3) as total
    from someothertable
) X

В приведенном выше синтаксисе SQL требуется псевдоним таблицы для подзаголовка, но он нигде не упоминается, поэтому я становлюсь ленивым и использую X или что-то в этом роде.

Ответ 9

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

Ответ 10

Использование полного имени затрудняет чтение, особенно для больших запросов или сценария Order/Product/OrderProduct

Я бы использовал t и s. Или o/p/op

Если вы используете SCHEMABINDING, тогда столбцы должны быть квалифицированы в любом случае

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

Из-за этой квалификации имеет смысл всегда использовать псевдонимы.

Использование a и b - слепое подчинение странному стандарту.

Ответ 11

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

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

Ответ 12

Я всегда использую их. Раньше я использовал их только в запросах, связанных только с одной таблицей, но затем я понял: а) запросы, связанные только с одной таблицей, встречаются редко, и б) запросы, связанные с одной таблицей, редко остаются таким образом надолго. Поэтому я всегда ставил их с самого начала, так что мне (или кому-то еще) не понадобилось бы ретро-подгонять их позже. Oh и BTW: Я называю их "именами корреляции", согласно стандарту SQL-92:)

Ответ 13

Табличные псевдонимы должны быть четырьмя:

  • Короткие
  • Значимые
  • Всегда используется
  • Используется последовательно

Например, если у вас были таблицы с именем service_request, service_provider, user и affiliate (среди многих других), хорошей практикой было бы присвоение таких таблиц как "sr", "sp", "u" и "a", и делать это в каждом запросе. Это особенно удобно, если, как это часто бывает, эти псевдонимы совпадают с аббревиатурами, используемыми вашей организацией. Поэтому, если "SR" и "SP" являются принятыми условиями для Service Request и Service Provider соответственно, вышеупомянутые псевдонимы несут двойную полезную нагрузку, интуитивно стоящую как для таблицы, так и для бизнес-объекта, который она представляет.

Очевидные недостатки этой системы в первую очередь состоят в том, что для имен таблиц может быть неудобно много "слов", например. a_long_multi_word_table_name, которое будет alias to almwtn или что-то еще, и что, вероятно, вы получите таблицы с такими именами, чтобы они сокращали их. Первый недостаток может быть рассмотрен, как вам нравится, например, взяв последние 3 или 4 буквы или любое другое подмножество, которое вы считаете наиболее представительным, наиболее уникальным или простым в типе. Второе, что я нашел на практике, не так хлопотно, как может показаться, возможно, просто на удачу. Вы также можете делать такие вещи, как взять вторую букву "слова" в таблице, например, aliasing account_transaction на "atr" вместо "at", чтобы избежать конфликта с account_type.

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

Ответ 14

В постах выше есть много хороших идей о том, когда и зачем называть имена таблиц. Никто еще не упомянул о том, что он также помогает помогать сопровождающему понять объем таблиц. В нашей компании нам не разрешено создавать представления. (Спасибо администратору базы данных.) Таким образом, некоторые из наших запросов становятся большими, даже превышая ограничение в 50 000 символов для команды SQL в Crystal Reports. Когда запрос создает псевдонимы своих таблиц как a, b, c и подзапрос, который делает то же самое, и несколько подзапросов в каждом из них используют одинаковые псевдонимы, легко ошибиться, какой уровень запроса читается. Это может даже запутать первоначального разработчика, когда прошло достаточно времени. Использование уникальных псевдонимов на каждом уровне запроса облегчает чтение, поскольку область действия остается ясной.

Ответ 15

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

Если запрос имеет дело только с одним источником - без JOIN - то я не использую псевдоним.

Просто вопрос личных предпочтений.

Ответ 16

Всегда. Сделайте это привычкой.