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

Question

Мне любопытно узнать, как люди используют псевдонимы таблиц. Другие разработчики, где я работаю, всегда используют псевдонимы таблиц и всегда используют псевдонимы 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 для таблицы сегментов.

Answer 1

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

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

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

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

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

Это хорошая привычка.

Answer 2

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

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

Мне это легче читать.

Answer 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

Answer 4

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

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

Answer 5

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

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

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

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 ...

Answer 6

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

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

Рассмотрим этот пример:

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 ...

Answer 7

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

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

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

Answer 8

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

Answer 9

Псевдонимов таблиц должно быть четыре вещи:

1. Short
2. Значимые
3. Всегда используется
4. Используется последовательно

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

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

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

Answer 10

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