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

Question

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

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

FROM incidents i
FROM cause_attack ca
FROM obscure_table ot

Спасибо.

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Я пытаюсь использовать имена говорящих таблиц, например, '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'.

Answer 4

Обычно я делаю то же самое, что и вы, за исключением того, что я использую только первую букву в верхнем регистре, пока у меня не будет нескольких таблиц, начинающихся с одного и того же имени, или нескольких ссылок на одну и ту же таблицу, затем я добавлю суффикс, чтобы различать два ... Что-нибудь, чтобы было понятно читателю. Если я использую ту же таблицу в подзапросе (скажем, таблицу Employee), что и во внешнем запросе, я могу использовать префикс 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, я могу внутренне прочитать псевдонимы как «Внутренний сотрудник» или «Внешний сотрудник»

Answer 5

Хотя я не являюсь парнем из 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

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

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

Answer 6

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

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

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

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