Когда использовать псевдоним таблицы 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

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

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

Answer 2

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

Я бы использовал т и с. Или о / п / оп

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

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

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

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

Answer 3

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

Answer 4

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

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 или что-то подобное.

Answer 5

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

Answer 6

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

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

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