Поскольку я уверен, что у многих людей другие стандарты, я сделал этот пост вики-сообществом.
У меня вопрос: какова хорошая схема именования псевдонимов таблиц? Я использовал первую букву каждого слова из названия таблицы, но оно становилось нечитаемым. Вот небольшой пример.
FROM incidents i
FROM cause_attack ca
FROM obscure_table ot
Спасибо.
Весь смысл псевдонима в том, чтобы сократить имя, чтобы вам не требовалось многословие.
Он должен быть уникальным только в рамках данного запроса, поэтому нет необходимости в схеме для их именования.
Изменить: Кроме того, псевдонимы, которые вы бы использовали, сильно зависят от схемы именования таблиц. Если все ваши таблицы имеют имя из 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
Опять же, префиксы служат напоминанием о «рекомендуемых» (и обязательных!) Псевдонимах таблиц при построении объединений. Использование префиксов упростило написание большинства запросов на соединение, поскольку очень редко приходилось явно ссылаться на таблицу перед полем, поскольку даже имена связанных полей имеют префиксы и, следовательно, уже имеют некоторую область видимости.
Хорошим побочным эффектом является то, что в конечном итоге ваши разработчики могут начать обращаться к таблицам в разговоре только с префикса. Приобретенный вкус, конечно ... Но у нас это работает.
