Именование объектов в Oracle. Взгляд "со стороны"

Artem_7

"Старая песня о главном"

"Стандарты именование объектов БД" и "правила оформления кода" темы не новые. Так или иначе, к вопросу выработки или заимствования таких стандартов и правил приходят все команды разработчиков. При желании в сети можно найти статьи и презентации по данной теме, а так же примеры и шаблоны различных соглашений. Многие из них безусловно полезны, некоторые - практически идеальны, если бы не одна маленькая оговорка: они написаны разработчиками и для разработчиков.

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

В принципе, пожелания по оформлению и именованию у "прикладника" (администратора приложения/технолога) и разработчика на 90 процентов совпадают. Но существуют все же некоторые отличия в восприятии "читателя" и "писателя", о которых я хотел бы поговорить.

Цель данной статьи: выработать свод правил именования объектов баз данных (мне нравится термин Naming Conventions - NC, по аналогии с Code Conventions) для применения командой разработчиков программных продуктов при проектировании информационных систем на базе СУБД Oracle, удовлетворяющий следующим требованиям:

NC должен быть максимально полон, т.е. содержать правила именования всех типов объектов БД
NC должен быть максимально краток. Идеальный вариант: 1 лист формата А4.

Почему именно СУБД Oracle? Мне она ближе и родней. А попытки объять необъятное с претензиями на универсальность не по моим зубам и компетенциям. В данном топике я попытался обобщить материалы статей Билла Коулэма (Bill Coulam), Стивена Ферстайна (Steven Feuerstein) и Тома Кайта (Tom Kyte) по данной теме и свой скромный опыт проектирования, разработки и эксплуатации различных информационных систем.

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

Вы еще здесь? Смогли сдержаться и не начали скроллить? Поздравляю, вам достается специальный бонус: вы можете скачать "Oracle NC"-плакат прямо здесь, не сходя с этого места. Дело в том, что я уже читал свою статью (да-да) и заранее предупреждаю: она громоздка и изобилует малопонятными с первого взгляда врезками-шаблонами. Воспринимать ее будет гораздо проще, имея под рукой все правила и примеры на одном листе.

Все знают, что главное в танке, но не каждый может сдержаться…

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

Полное отсутствие признаков NC (2 продукта из 12-ти). Это кошмар. Эксплуатировать такую систему все равно, что собирать пазл картинкой вниз. Ценой неимоверных усилий из клубка удается вытянуть только отдельные нити взаимосвязей и логики. И каждый раз, при новой проблеме клубок приходится распутывать заново.
Использование различных NC в одном проекте (3 продукта из 12-ти). Сразу видно, что разработчики слышали об NC, выработали собственный стиль и научились его соблюдать. Проблема в том, что разработчиков и стилей было слишком много для одного проекта. Эксплуатация таких решений затрудняется тем, что опыт изучения отдельного модуля оказывается бесполезен в другом. Познав часть нельзя получить достоверное представление о целом.
NC, которые четко прослеживались в ранних версиях, погребены под грудой костылей и вымыты мощным напором патчей (6 продуктов из 12-ти). Самый распространенный вариант. Тот самый танк, в котором не смогли сдержаться.
Четко зафиксированные NC с соблюдением всех требований и ограничений на протяжении всего жизненного цикла системы. (1 продукт из 12-ти). Вот она мечта прикладника…

Я не хочу углубляться в анализ причин п.п. 1-3, я просто констатирую факт. Все, что я хочу - помочь сделать шаг к "мечте" п. 4. Итак, начнем.

Общие рекомендации

Начнем с того, о чем следует помнить и чему следовать при разработке под СУБД Oracle:

Помните, что имена объектов в Oracle ограничены по длине 30-ю символами. Исчерпывающе. От себя могу добавить только пожелание. Если вы не хотите, чтобы люди, работающие с вашей системой через приложения, не поддерживающие "подсказчик кода", сошли с ума, будьте благоразумны - старайтесь, чтобы названия ваших объектов были как можно короче.
Помните, что имена объектов не могут начинаться с цифры. Без комментариев.
При именовании объектов пользуйтесь одним языком. Желательно, английским. Избегайте транслитерации. Поверьте, таблица с названием ORDERS воспринимается лучше, чем таблица с названием ZAKAZ . И еще. Очень часто в коммерческих системах приходится сталкиваться с транслитерацией аббревиатур. Избегайте и ее. USSR понятнее, чем SSSR , а USA понятней, чем SSHA Как-то так.
Да, чуть не забыл. Пользуйтесь в наименованиях только латиницей! Конечно, это рекомендация для идиотов, но я один раз чуть не свихнулся, пытаясь сделать выборку из таблицы в SQLPLUS. А все потому, что в самом конце там затесался символ "е" в русской раскладке. В PL/SQL Developer мне не приходилось набирать название полностью - работал подсказчик кода. Самое смешное, что таблица прожила в таком виде больше месяца и до меня на нее никто не жаловался.
В процессе проектирования вашей системы (сразу после обследования предметной области) перепишите все выявленные сущности в отдельный файл (таблицу - глоссарий). Не поленитесь порыться в Интернете - для большинства ваших сущностей уже давно существуют общепринятые и устоявшиеся англоязычные наименования. Зафиксируйте их в глоссарии. Для остальных сущностей сделайте хороший перевод. То же самое проделайте для предполагаемых аббревиатур. Ну, а дальше самое главное: всегда используйте одни и те же названия для одинаковых по смыслу элементов.
Избегайте использования зарезервированные слов Oracle в качестве наименований (список всех зарезервированных слов можно получить, сделав выборку из системного представления V$RESERVED_WORDS). К слову, некоторые слова из данного представления Oracle и так не даст использовать. Но есть и такие, которые использовать прямо не запрещено, но лучше, все-таки, этого не делать.
Разделяйте в наименованиях объектов лексемы символом подчеркивания. Помните, что Oracle не чувствителен к регистру наименований, поэтому ваши "верблюды" вроде MySuperPuperTableName превратятся в словаре в абсолютно нечитаемые MYSUPERPUPERTABLENAME .

Небольшое лирическое отступление

Правила именования объектов

Таблицы

В вопросе именования таблиц я почти полностью разделяю точку зрения Билла Коулэма. Разработанный им стандарт исчерпывающ и практически идеален, как для разработчика, так и для "эксплуататора". Я не буду приводить здесь полный перевод, остановлюсь только на основополагающих моментах.

Итак, Коулэм предлагает следующую универсальную форму именования таблицы (фигурные скобки включают обязательные компоненты, а "прямые" скобки - опциональные):
[Модуль_][Группа_]{Наименование}[_Роль]
Под Модулем (в терминах Коулэма - системная группа) понимается наименование подсистемы внутри нашей базы данных. Обычно используется сокращение в 2-4 символа. Например, таблицы модуля "Тарификатор" могут иметь префикс "TAR_", а таблицы Платежного модуля префикс "PAY_". От себя добавлю, что если разработка ведется в "чужой" схеме желательно добавлять дополнительный префикс для разделения своих и чужих объектов. Обычно я добавляю в префикс сокращенное наименование своей организации. Конечно, это удлиняет названия объектов, зато позволяет четко выделить "свои" объекты в дереве проекта. Если вас смущает такой подход, вполне достаточно добавить перед кодом модуля один символ ("локальные разработчики" обычно предпочитают Х или ХХ -наследие OEBS ?!).

Группа используется для тех же целей: она позволяет группировать сущности, логически связанные между собой (обычно до 20 объектов в группе). Представляет собой так же сокращение в 2-4 символа. Использование системной и логических групп позволяет не только группировать сущности в дереве объектов, но и существенно упрощает разработку и сопровождение системы в целом. Действительно, исчезает необходимость запоминать наименования конкретных объектов, достаточно помнить аббревиатуры модуля и логической группы, а дальше подсказчик кода поможет легко найти необходимый вам объект.

С Наименованием все понятно. Это и есть фактическое название сущности. Билл Коулэм рекомендует использовать единственное число, но лично мне ближе и привычнее множественное (Стивен Ферстайн, привет!). И Стивен и Билл советуют избегать сокращений в наименованиях сущностей. Исключения - слова длиннее 8 символов.

Не всегда назначение таблицы удается выразить одним словом. В этом случае некоторые отечественные разработчики по привычке пользуются правилом, которое я про себя называю "Правилом товарного чека", когда порядок слов идет от общего к частному, от сущности к свойствам. Т.е. "Бумага туалетная", вместо "Туалетная бумага", "Огурцы маринованные", а "Паста томатная". К сожалению, в англоязычных наименованиях это чаще всего выглядит ужасно. Сравните YELLOW_SUBMARINE и SUBMARINE_YELLOW . В данном случае я не вижу смысла опираться на единый шаблон, а рекомендую использовать тот порядок, который более уместен в конкретном контексте.

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

_AUD - Таблицы, хранящие историю изменений строк базовой таблицы (журнальные таблицы). Встречал в разных системах для данного типа таблиц суффиксы _JN (журнал) и _HIST. Сам раньше использовал суффикс _AUDIT, сейчас _JN. А _AUD мне привычней видеть в названии триггера.
_LOG - таблицы фиксации сообщений приложения (лог-таблицы)
_HIST - Архивные таблицы, в которые осуществляется выгрузка устаревших данных. Для такого типа таблиц я использую суффикс _ARCH
_TYPE - таблицы-справочники, строки которых представляют собой перечень уникальных значений. Отечественные разработчики для таблиц справочников часто используют суффикс _REF. Мне тоже суффикс _REF больше по душе из-за того, что слово _TYPE очень любимо разработчиками и часто является частью компонента Наименование.
_GT - Глобальные временные таблицы. Стивен Ферстайн рекомендует для них использовать суффикс _TMP или _TEMP, но это, на мой взгляд, противоречит нашей ментальности. Русский программист привык использовать лексему _TEMP для пометки всякого временного "мусора", поэтому _GT и только _GT.

В отдельный класс Коулэм выделяет таблицы, посредством которых реализуется взаимосвязь "многие-ко-многим". Для таких таблиц он предлагает следующий шаблон именования:
[Модуль_]{Имя/Код таблицы 1_Имя/Код таблицы 2}
В большинстве проектов, с которыми я сталкивался, для таких таблиц-ассоциаций разработчики использовали "значащие" имена. Сам я использую шаблон:
[Модуль_][Группа_]{Код таблицы 1_}{Код таблицы 2}
Код таблицы в данном случае представляет собой сокращенное наименование таблицы, которая участвует в связке (2-4 символа). Например, таблица, хранящая связи студентов ( STUDENTS ), посещающих лекции преподавателей ( TEACHERS ) в данном стандарте будет называться STUD_TCHR . Да, на первый взгляд выглядит отталкивающе, но со временем понимаешь удобство: с первого взгляда классифицируешь таблицу как "связку" (благодаря использованию кодов/аббревиатур вместо полных имен), сразу видишь, какие сущности связываются.

Колонки (столбцы) таблиц

Начнем с ограничений общей длины наименования - старайтесь уложиться в 15 символов (лучше - меньше). Запас до верхнего ограничения вам понадобится для последующего именования ограничений, индексов и столбцов с внешним ключом.
В своих проектах я использую следующий шаблон:
[Код таблицы_]{Наименование столбца}[_Роль]
Код таблицы представляет собой сокращенное наименование таблицы, которой принадлежит колонка (2-4 символа). Хоть я и обозначил данный префикс опциональным, я его использую почти для всех столбцов. Исключение - "служебные" столбцы, которые хранят значение неких свойств абстрактной записи любой таблицы, а не свойств конкретного объекта (например, UPDATE_DATE , UPDATE_BY и т.п.).

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

Роль - опциональный суффикс. Обращаю внимание, что это тип значения столбца, а не код типа данных этого столбца! Чаще всего я использую следующие роли (типы значений):

_ID - идентификатор объекта на базе суррогатного ключа
_NUM - строковое поле, содержащее какой-нибудь номер.
_CODE - строковый ключ сущности (уникальный для таблиц-справочников).
_DESC - Краткое описание сущности
_YN - поле типа CHAR(1), принимающее значения Y(es) или N(o)

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

Более читабельные запросы. По столбцу с префиксом сразу понимаешь, о какой таблице идет речь. Не секрет, что часто разработчикам лень развернуто квалифицировать столбцы, поэтому наименование столбца с префиксом делает работу с "чужими" запросами легче.
Облегчается диагностика исключений (ошибок). Конечно, большая их часть ссылается на ограничения, а не на конкретные столбцы, но имя ограничения почти всегда базируется на имени столбца.
Снижается вероятность совпадения наименования столбца с зарезервированными словами из системного словаря. Особенно это касается таких распространённых наименований, как NAME, ID, COMMENT и DATE. Как следствие, разработчик освобождается от необходимости добавления в наименование других избыточных сочетаний символов.
У нас в компании сложилось так, что большая часть используемого клиентского ПО разработано на базе Oracle Forms, где для любого поля по кнопке F1 можно посмотреть наименование столбца-источника. Возможность мгновенно связать объект на форме с объектом в БД очень помогает и при начальном знакомстве с системой и при дальнейшей эксплуатации.

Ограничения

Коулэм рекомендует именовать ограничения, используя префикс в виде полного имени таблицы, на которую данное ограничение распространяется. Я считаю такое именование необоснованным расточительством, особенно с учетом общего лимита в 30 символов на длину наименования. Поэтому стараюсь, где возможно использовать Код таблицы вместо полного имени. Таким образом, для первичного ключа получаем:
[Модуль_][Группа_]{Код таблицы}{_PK}
Здесь и далее префиксы Модуль и Группа ограничения получают в "наследство" от таблицы, с которой они связаны. Это позволяет избежать нарушений уникальности при формировании имен в больших системах, а так же удобно группировать ограничения по модулям.

Для уникального ключа, построенного на одном столбце:
[Модуль_][Группа_]{Шаблон столбца}{_UK}
Напоминаю, что шаблон столбца у нас включает Код таблицы. Таким образом, для колонки PRM_CODE таблицы UTL_PARAMS_REF уникальный ключ будет называться UTL_PRM_CODE_UK

Для уникального ключа, построенного на нескольких столбцах:
[Модуль_][Группа_]{Код таблицы_}{CОMP_UK}[_#]
COMP - в данном случае обозначает COMPOSITE (признак составного ключа), # (порядковый номер) используется если уникальных составных ключей несколько (если честно, я не могу придумать вменяемый пример для такого случая).

Внешний ключ на базе одного столбца:
[Модуль_][Группа_]{Шаблон столбца}{_FK}
Так как полное наименование столбца внешнего ключа у нас содержит Коды дочерней и родительской таблиц, то для колонки PVL_PRM_ID таблицы UTL_PARAM_VALUES внешний ключ будет называться UTL_PVL_PRM_ID_FK (ссылается на столбец PRM_ID таблицы UTL_PARAMS_REF )

Внешний ключ, построенный на нескольких столбцах:
[Модуль_][Группа_]{Код таблицы_}{COMP_FK}[_#]
Ограничение на уровне столбца:
[Модуль_][Группа_]{Шаблон столбца}{_CK}
Ограничение на уровне таблицы:
[Модуль_][Группа_]{Код таблицы_}{COMP_CK}[_#]
На просторах Интернета я часто встречал горячие обсуждения необходимости именования ограничения типа NOT NULL . Да, согласен, лениво, но если строго придерживаться концепции, то:
[Модуль_][Группа_]{Шаблон столбца}{_NN}

Индексы

Индексы я обычно делю на три категории:

Индексы на базе ключей (первичного и уникального)
Индексы на базе одного столбца
Составные (на базе нескольких столбцов)

Индексы на базе ключей (первичного и уникального) именуются так же, как и соответствующие им ограничения:

[Модуль_][Группа_]{Код таблицы}{_PK} [Модуль_][Группа_]{Шаблон столбца}{_UK} [Модуль_][Группа_]{Код таблицы_}{CОMP_UK}[_#]

Индексы на базе одного столбца:
[Модуль_][Группа_]{Шаблон столбца}[_Роль]{_IDX}
Под Ролью в данном шаблоне понимается модификатор типа индекса. Коулэм рекомендует использовать следующие модификаторы:

L - локальный партицированный индекс
G - Глобальный индекс на партицированной таблице
B - Bitmap-индекс
F - Индекс на основе функции
C - compressed-индекс (сжатый)
R - reverse key индекс (индекс с обратным порядком следования ключей)
U - уникальный индекс

Индексы на основе нескольких столбцов. Коулэм рекомендует следующую форму:
[Модуль_][Группа_]{Код таблицы}{_COMP}[_Роль]{_IDX}[#]
Я считаю шаблон Коулэма частным случаем и всегда стараюсь перечислить все столбцы (если при этом не нарушается ограничение по длине) в наименовании индекса:
[Модуль_][Группа_]{Код таблицы_}{Список столбцов}[_Роль]{_IDX}
Почему я ограничиваюсь модификатором COMP для ограничений, но стараюсь не использовать его для индексов? Все дело в том, что составные ограничения все-таки являются скорее исключением, чем правилом. Их обычно не очень много, да и сообщение с ошибкой об их нарушении встречаются не очень часто. Другое дело - составные индексы. Во-первых, их просто много. Во-вторых, их часто больше одного на таблицу. И, в третьих, разработчик и администратор приложения работает с ними постоянно, проверяя планы запросов.

Триггеры

В данной статье я рассматриваю только триггеры DML, потому что считаю, что все остальные типы относятся больше к зоне ответственности DBA, а не разработчика. Триггеры я именую по следующим правилам:
[Модуль_][Группа_]{Код таблицы}[_Цель/Роль]_{B/A/C (I/U/D)[S]}[_#]
Где аббревиатуры B, А, С ( BEFORE , AFTER , COMPOUND ), определяют "момент" срабатывания триггера; I, U, D ( INSERT , UPDATE , DELETE ) - событие срабатывания; S ( STATEMENT ) - определяют "уровень" срабатывания.

В своих проектах я выделяю две "типизированные" Цели (роли) триггеров:

AUDIT - триггеры, фиксирующие изменения основной таблицы в журнальной (например, UTL_PRM_AUDIT_AIUD )
INIT - "инициализирующие" триггеры, отвечающие за генерацию суррогатных ключей и заполнение значений по-умолчанию для столбцов (например, UTL_PRM_INIT_BI )

Представления

Правила именования представлений ничем не отличаются от правил именования таблиц. Единственное пожелание - включать в наименование признак, что данный объект является именно представлением. Подходы тут могут быть разные. Я встречал данный признак в виде префикса имени. Например, V_ или даже V$, как у системных представлений Oracle. Лично я использую суффиксы:

$V - для обычных представлений
$MV - для материализованных

Но вам не посоветую. Знак доллара в качестве разделителя - дело привычки. Это "якорь" для моих глаз, который позволяет отличить таблицу от представления. Объективно на данных подход я взглянуть не могу, поэтом ничего не имею против знака "нижнего подчеркивания", как у Ферстайна (суффиксы _V и _MW).

Последовательности

Последовательности я выделяю среди других объектов суффиксом _SEQ и рекомендую именовать по следующему правилу:

[Модуль_][Группа_]{Код таблицы / Полное наименование столбца / Цель}{_SEQ}

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

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

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

Синонимы

Синонимы именуются так же, как и объекты, на которые они ссылаются

Типы

По типам, у меня нет окончательно сформированного мнения. Я встречал разные подходы к именованию этих объектов, но так и не смог до конца определиться, какой подход мне ближе. Опишу здесь те, которые не вызывают во мне негативных реакций:
[Модуль_][Группа_]{Наименование}[_Признак коллекции]T
Данный шаблон рекомендует Коулэм. Признак коллекции типа обознается символом Т. Таким образом, тип одиночного объекта всегда имеет суффикс _T, тип коллекции - _TT. Например, UTL_PARAMETER_T , UTL_PARAMETER_TT .
[Модуль_][Группа_]{Наименование}[S]_TYP
Здесь S обозначает множественное число, а суффикс TYP квалифицирует объект БД как тип. Например, UTL_PARAMETER_TYP , UTL_PARAMETERS_TYP . Это подход мне нравится менее всего, потому что признак коллекции не выделен и глаз за него не цепляется.
[Модуль_][Группа_]{Наименование}_{OBJ / TAB}
В данной нотации, если наименование объекта БД заканчивается на OBJ или TAB, то объект является типом (TAB - коллекция, OBJ - одиночный объект). Например, UTL_PARAMETER_OBJ , UTL_PARAMETERS_TAB

Программные модули

Правила оформления кода программных модулей я хотел бы выделить отдельную статью. Здесь приведу шаблон, предлагаемый Коулэмом. Для пакетов процедур Билл использует следующее правило:
[Модуль_][Группа_]{Цель/Назначение}[_Функцион. модификатор][_PKG]
В терминах NC Коулэма Функциональный модификатор (для меня понятнее термин Подгруппа) используется при выделении каких-то функций в отдельный пакет при рефакторинге. Скажем так, это дополнительный уровень логической группы. Например, пакет UTIL содержал функции работы с числами и строками. Его разбили на два: UTIL_NUMBER и UTIL_STRING .

При разработке в PL/SQL специалист постоянно оперирует функциями и процедурами других пакетов. Чтобы код не смотрелся громоздким, я стараюсь избегать ненужного удлинения в наименовании пакетов. Поэтому суффикс _PKG использую только в случаях, когда наименование пакета может совпадать с наименованием другого объекта схемы.

Для отдельных процедур и функций Коулэм рекомендует следующий шаблон:
[Действие_]{Цель/Назначение}
Под действием понимается глагол ( GET , SET , ASSIGN , RUN ), под целью - то, что необходимо сделать. Со своей стороны, я стараюсь вообще не использовать процедуры и функции вне пакетов при разработке. Кроме того, те же функции у меня часто группируются по объектам, с которыми они работают, поэтому я обычно использую шаблон
{Цель}[_Действие]
Таким образом, подсказчик кода отлично группирует процедуры по объектам: PARAM_GET , PARAM_SET , PARAM_CHECK и т.п.

Заключение

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

P.S. Внимательный читатель безусловно заметил мой маленький обман. Первая цель статьи так и не была достигнута: далеко не все типы объектов СУБД Oracle описаны в статье и присутствуют в NC-плакате. Что же, у вас есть шанс исправить этот недочет. Вы можете скачать "исходник" NC-плаката и отредактировать его под свои цели и задачи.

В статье использованы следующие источник:

Блог Стивена Ферстейна (Steven Feuerstein) и его Naming Convention and Code Standards
Oracle Naming Standard Билла Коулэма (Bill Coulam)
Блог Тома Кайта (Tom Kyte) Ask Tom...
Материалы форума SQL.RU