Когда использовать SQL-таблицу Alias ​​

Question

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

Вот пример:

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

Answer 6

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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

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

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

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

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

Answer 9

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

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

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

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

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

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

Answer 10

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

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

Answer 11

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

Answer 12

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

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 буквы или любое другое подмножество, которое вы считаете наиболее представительным, наиболее уникальным или простым в типе. Второе, что я нашел на практике, не так хлопотно, как может показаться, возможно, просто на удачу. Вы также можете делать такие вещи, как взять вторую букву «слова» в таблице, например, aliasing account_transaction to «atr» вместо «at», чтобы избежать конфликта с account_type.

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

Answer 13

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

• они делают запросы более читаемыми (мои псевдонимов 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 14

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

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

Answer 15

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