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

Question

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

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

FROM incidents i 
FROM cause_attack ca 
FROM obscure_table ot 

спасибо.

Answer 1

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

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

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

Answer 2

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

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

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

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), как во внешнем запросе, я могу использовать префикс я или о к distinquish, а в

-- 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, Я могу внутренне читать псевдонимы «Inner Сотрудник» или «Outer Сотрудник»

Answer 5

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

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

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

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

Answer 6

Хотя я не парень Oracle (на самом деле, этот вопрос должен применяться практически в любой РСУБД), мой answer to "What was the strangest coding standard rule that you were forced to follow", кажется, относится хорошо здесь (отредактирован, чтобы иметь смысл в контексте этого поста) ...

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

Вот схема: каждая таблица названа во всех шапках, с подчеркиваниями между словами. Каждая таблица имеет префикс (обычно 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 

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

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