«Старая песня о главном»
«Стандарты именование объектов БД» и «правила оформления кода» темы не новые. Так или иначе, к вопросу выработки или заимствования таких стандартов и правил приходят все команды разработчиков. При желании в сети можно найти статьи и презентации по данной теме, а так же примеры и шаблоны различных соглашений. Многие из них безусловно полезны, некоторые — практически идеальны, если бы не одна маленькая оговорка: они написаны разработчиками и для разработчиков.
К сожалению, в моей субъективной реальности разработчики являют собой лишь некую абстракцию. Эдакие фантомы по ту сторону телефонной трубки, от которых меня отделяют тысячи километров и 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.
Небольшое лирическое отступлениеЧестно говоря, в Oracle можно задать регистрозависимое наименование для объекта. Например, вот так:
create table "MyTable" (a number);Короче, избегайте таких извращений.
Правила именования объектов
Таблицы
В вопросе именования таблиц я почти полностью разделяю точку зрения Билла Коулэма. Разработанный им стандарт исчерпывающ и практически идеален, как для разработчика, так и для «эксплуататора». Я не буду приводить здесь полный перевод, остановлюсь только на основополагающих моментах.
Итак, Коулэм предлагает следующую универсальную форму именования таблицы (фигурные скобки включают обязательные компоненты, а «прямые» скобки – опциональные):
[Модуль_][Группа_]{Наименование}[_Роль]Под Модулем (в терминах Коулэма — системная группа) понимается наименование подсистемы внутри нашей базы данных. Обычно используется сокращение в 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
Автор: Artem_7
