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

в 18:22, , рубрики: Без рубрики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Помните, что имена объектов в Oracle ограничены по длине 30-ю символами. Исчерпывающе. От себя могу добавить только пожелание. Если вы не хотите, чтобы люди, работающие с вашей системой через приложения, не поддерживающие «подсказчик кода», сошли с ума, будьте благоразумны — старайтесь, чтобы названия ваших объектов были как можно короче.
  2. Помните, что имена объектов не могут начинаться с цифры. Без комментариев.
  3. При именовании объектов пользуйтесь одним языком. Желательно, английским. Избегайте транслитерации. Поверьте, таблица с названием ORDERS воспринимается лучше, чем таблица с названием ZAKAZ. И еще. Очень часто в коммерческих системах приходится сталкиваться с транслитерацией аббревиатур. Избегайте и ее. USSR понятнее, чем SSSR, а USA понятней, чем SSHA Как-то так.
  4. Да, чуть не забыл. Пользуйтесь в наименованиях только латиницей! Конечно, это рекомендация для идиотов, но я один раз чуть не свихнулся, пытаясь сделать выборку из таблицы в SQLPLUS. А все потому, что в самом конце там затесался символ «е» в русской раскладке. В PL/SQL Developer мне не приходилось набирать название полностью — работал подсказчик кода. Самое смешное, что таблица прожила в таком виде больше месяца и до меня на нее никто не жаловался.
  5. В процессе проектирования вашей системы (сразу после обследования предметной области) перепишите все выявленные сущности в отдельный файл (таблицу — глоссарий). Не поленитесь порыться в Интернете — для большинства ваших сущностей уже давно существуют общепринятые и устоявшиеся англоязычные наименования. Зафиксируйте их в глоссарии. Для остальных сущностей сделайте хороший перевод. То же самое проделайте для предполагаемых аббревиатур. Ну, а дальше самое главное: всегда используйте одни и те же названия для одинаковых по смыслу элементов.
  6. Избегайте использования зарезервированные слов Oracle в качестве наименований (список всех зарезервированных слов можно получить, сделав выборку из системного представления V$RESERVED_WORDS). К слову, некоторые слова из данного представления Oracle и так не даст использовать. Но есть и такие, которые использовать прямо не запрещено, но лучше, все-таки, этого не делать.
  7. Разделяйте в наименованиях объектов лексемы символом подчеркивания. Помните, что 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)

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

  1. Более читабельные запросы. По столбцу с префиксом сразу понимаешь, о какой таблице идет речь. Не секрет, что часто разработчикам лень развернуто квалифицировать столбцы, поэтому наименование столбца с префиксом делает работу с «чужими» запросами легче.
  2. Облегчается диагностика исключений (ошибок). Конечно, большая их часть ссылается на ограничения, а не на конкретные столбцы, но имя ограничения почти всегда базируется на имени столбца.
  3. Снижается вероятность совпадения наименования столбца с зарезервированными словами из системного словаря. Особенно это касается таких распространённых наименований, как NAME, ID, COMMENT и DATE. Как следствие, разработчик освобождается от необходимости добавления в наименование других избыточных сочетаний символов.
  4. У нас в компании сложилось так, что большая часть используемого клиентского ПО разработано на базе 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}

Индексы

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

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

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

[Модуль_][Группа_]{Код таблицы}{_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-плаката и отредактировать его под свои цели и задачи.

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

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

Автор: Artem_7

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js