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

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

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

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

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

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

Для меня это просто облегчает чтение.

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

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

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 или что-то в этом роде.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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