Читаемые псевдонимы SQL

Весь смысл псевдонима состоит в том, чтобы сократить имя, чтобы вам не требовалось многословие.

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

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

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

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

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

Обычно я стараюсь следовать структуре именования таблиц.

Я стараюсь использовать говорящие имена таблиц, такие как 'RelObjectProperty', и последовательно присваивать им псевдонимы, как (для этого примера) 'rop':

SELECT
  p.Name    PropertyName,
  o.Name    ObjectName,
  rop.Value PropertyValue
FROM
  Property p
  INNER JOIN RelObjectProperty rop ON rop.PropertyId = p.Id
  INNER JOIN Object              o ON rop.ObjectId   = o.Id
WHERE
  o.Id = 10

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

Там может быть таблица 'RelObjectPresentation', и в этом случае я бы, скорее всего, сломал схему и использовал 'rop' для первого и 'ropr' для второго. Даже в этом случае я был бы последовательным в своей непоследовательности и, по крайней мере, использовал бы псевдоним 'ropr'везде, а не только в запросах, где мне нужно отличать от 'rop'.

Я обычно делаю то же самое, что и вы, за исключением того, что использую только первую букву в верхнем регистре, пока у меня не будет несколько таблиц, начинающихся с одного и того же имени, или несколько ссылок на одну и ту же таблицу, а затем я добавляю суффикс, чтобы различать две .. Все, что угодно, чтобы читателю было понятно. Если я использую ту же таблицу в подзапросе (например, таблицу сотрудников), что и во внешнем запросе, я могу использовать префикс i или o для различения, как в

-- Find Highest paid Emplyees in Each Division ..... 
Select * From Employee oE -- For outer Employee table
Where Salary = (Select Max(Salary) 
                From Employee iE
                Where DivisionId = oE.DivisionId) 

Таким образом, когда я читаю SQL, я могу внутренне читать псевдонимы как «Внутренний сотрудник» или «Внешний сотрудник».

В сценарии размещения данных я обычно использую первые символы, но префикс либо fact_, dim_, либо cdim_, чтобы различать таблицы фактов, измерений или согласованных измерений. Я также сделаю lkup_ для поиска (так что LOOKUP_TRANSACTION_TYPE станет lkup_TT).

Метод поиска будет работать и в базах данных типа OLTP.

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

Это хорошее преимущество перед техникой A, B, C или T1, T2, T3, потому что она отслеживается и помогает избежать ошибок вырезания и вставки.

Хотя я не специалист по Oracle (на самом деле, этот вопрос должен относиться практически к любой СУБД), мой ответ на вопрос "Какое самое странное стандартное правило кодирования, которому вы были вынуждены следовать", похоже, хорошо применим здесь (отредактировано, чтобы иметь смысл в контексте этого сообщения) ...

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

Вот схема: каждая таблица названа заглавными буквами с подчеркиванием между словами. Каждая таблица имеет префикс (обычно от 1 до 6 символов), который обычно является аббревиатурой или сокращением имени основной таблицы. Каждое поле таблицы также имеет один и тот же префикс. Префиксы также используются в сложных запросах в качестве псевдонимов. Итак, допустим, у вас есть простая схема, в которой люди могут владеть кошками или собаками. Это выглядело бы так:

PER_PERSON
    PER_ID
    PER_NameFirst
    PER_NameLast
    ...
CAT_CAT
    CAT_ID
    CAT_Name
    CAT_Breed
    ...
DOG_DOG
    DOG_ID
    DOG_Name
    DOG_Breed
    ...
PERCD_PERSON_CAT_DOG (for the join data)
    PERCD_ID
    PERCD_PER_ID
    PERCD_CAT_ID
    PERCD_DOG_ID

Опять же, префиксы служат напоминанием о «рекомендуемых» (и обязательных!) Псевдонимах таблиц при построении объединений. Использование префиксов упростило написание большинства запросов на соединение, поскольку очень редко приходилось явно ссылаться на таблицу перед полем, поскольку даже имена связанных полей имеют префиксы и, следовательно, уже имеют некоторую область видимости.

Хорошим побочным эффектом является то, что, в конце концов, ваши разработчики могут начать обращаться к таблицам в разговоре только с префикса. Приобретенный вкус, конечно ... Но у нас это работает.