- Таблицы
- Создание таблицы
- Создание таблицы с несколькими полями
- Значения по умолчанию
- Понятие NULL. Not-null колонки
- Комментарии к таблице, колонкам
- База данных Oracle Database для начинающих: основы базы данных
- Теория и практика
- Добавление колонки
- Удаление колонки
- Удаление таблицы из базы данных Oracle
- Важные замечания
- Возможные вопросы
- Именование объектов в Oracle. Взгляд «со стороны»
- «Старая песня о главном»
- Все знают, что главное в танке, но не каждый может сдержаться…
- Общие рекомендации
- Правила именования объектов
- Заключение
Таблицы
Данные в реляционных базах данных хранятся в таблицах. Таблицы — это ключевой объект, с которыми придется работать в SQL.
Таблицы в БД совсем не отличаются от тех таблиц, с которыми все уже знакомы со школы — они состоят из колонок и строк.
Каждая колонка в таблице имеет своё имя и свой тип, т.е. тип данных, которые будут в ней содержаться. Помимо типа данных для колонки можно указать максимальный размер данных, которые могут содержаться в этой таблице.
Например, мы можем указать, что для колонки возраст тип данных — это целое число, и это число должно состоять максимум из 3-х цифр. Т.о. максимальное число, которое может содержаться в этой колонке = 999. А с помощью дополнительных конструкций можно задать и правила проверки корректности для значения в колонке,- например, мы можем указать, что для колонки возраст в таблице минимальное значение = 18.
Создание таблицы
После выполнения данной sql-команды в базе данных будет создана таблица под названием hello . Эта таблица будет содержать всего одну колонку под названием text_to_hello . В этой колонке мы можем хранить только строковые значения(т.е. любой текст, который можно ввести с клавиатуры) длинной до 100 байт.
Обратите внимание на размер допустимого текста в колонке text_to_hello . 100 байт — это не одно и то же, что и 100 символов! Для того, чтобы сказать базе данных Oracle, что длина строки может быть 100 символов, нужно было определить столбец следующим образом:
Создание таблицы с несколькими полями
В таблице может много столбцов. Напимер, можно создать таблицу с тремя, пятью или даже 100 колонками. В версиях oracle с 8i по 11g максимальное количество колонок в одной таблице достигает 1000.
Для того, чтобы создать таблицу с несколькими колонками, нужно перечислить все колонки через запятую.
Например, создадим таблицу cars , в которой будем хранить марку автомобиля и страну-производитель:
Эта таблица может содержать, например, такие данные:
Следует обратить внимание на последние 2 строки в таблице cars — они не полные. Первая из них содержит данные только в колонке model , вторая — не содержит данных ни в одной из колонок. Эта таблица может даже состоять из миллиона строк, подобных последней — и каждая строка не будет содержать в себе абслютно никаких данных.
Значения по умолчанию
При создании таблицы можно указать, какое значение будет принимать колонка по умолчанию:
В этом примере создается таблица cars, в которой помимо модели и страны-производителя хранится еще и количество колес, которое имеет автомобиль. И поле wheel_count по-умолчанию будет принимать значение, равное 4.
Что значит по-умолчанию? Это значит, что если при вставке данных в эту таблицу не указать значение для колонки wheel_count , то оно будет равно числу 4.
Понятие NULL. Not-null колонки
Ячейки в таблицах могут быть пустыми, т.е. не содержать значения. Для обозначения отсутствия значения в ячейке используется ключевое слово NULL . Null могут содержать ячейки с любым типом данных.
Рассмотрим таблицу cars из предыдущего примера. В каждой из трех ее колонок может храниться Null(даже в колонке wheel_count , если указать значение Null явно при вставке).
Но представляют ли информационную ценность строки в таблице, где абслютно нет значений? Конечно нет. Если рассматривать таблицу cars как источник информации об автомобилях, то нам хотелось бы получать хоть какую-то полезную информацию. Наиболее важной здесь будет колонка model — без нее информация о стране-производителе и количестве колес будет бесполезной.
Для того, чтобы запретить Null-значения в колонке при создании таблицы, к описанию колонки добавляется not null :
Теперь БД гарантирует, что колонка model не будет пустой, по крайней мере до тех пор, пока флаг not null включен для этой колонки.
Также можно указать, что колонка wheel_count тоже не должна содержать Null :
Комментарии к таблице, колонкам
Для создаваемых таблиц и их колонок можно указывать комментарии. Это значитально облегчит понимание того, для чего и как они используются.
Например, укажем комментарии для таблицы cars и ее колонок:
Для того, чтобы удалить комментарий, нужно просто задать в качестве его значения пустую строку:
Источник
База данных Oracle Database для начинающих: основы базы данных
Мы научились создавать таблицы в базе данных Oracle на предыдущем шаге. Таблицы и колонки таблиц, их названия, расположение, последовательность колонок, типы данных колонок называются структурой таблицы.
Структуру таблицы можно менять, то есть добавлять новые колонки в таблицу, удалять колонки из таблицы, менять типы данных у заданной колонки. Также, если таблица нам больше не нужна или просто надоела, существует возможность такую таблицу удалить.
Теория и практика
Существует несколько команд для изменения структуры таблицы, добавления, удаления или изменения типа данных колонки таблицы.
Все эти команды объединяет то, что они начинаются с ключевой команды ALTER TABLE .
Добавление колонки
Добавляем новую колонку к нашей таблице.
Синтаксис:
TABLE_NAME – наименование таблицы.
Column_NAME – наименование колонки.
Column_type – тип данных колонки ( VARCHAR (n) или NUMBER или DATE ).
Примеры:
Пусть у нас есть таблица GOODS, необходимо добавить колонку itemprice типа NUMBER , цена изделия.
Пусть у нас есть таблица MANS, необходимо добавить колонку DATEreg типа DATE , дата регистрации, и колонку patronymic – отчество VARCHAR2 (50) .
Удаление колонки
Также мы можем удалить колонку из заданной таблицы с помощью специальной SQL-команды DROP COLUMN .
Синтаксис:
Примеры:
Пусть у нас есть таблица GOODS, необходимо удалить колонку COLOR .
Пусть у нас есть таблица MANS, необходимо удалить колонку YEAROLD .
Меняем тип данных для колонки таблицы.
Синтаксис изменения типа колонки:
Сolumn_NAME – наименование колонки.
Data_type – тип данных колонки ( VARCHAR (n) или NUMBER или DATE ).
Примеры:
– заменить в таблице MANS тип поля NAME на VARCHAR2 (90) ;
– заменить в таблице GOODS тип поля INSERT_DATE на DATE;
Удаление таблицы из базы данных Oracle
Синтаксис команды SQL для удаления таблицы:
Здесь TABLE_NAME – наименование таблицы.
Примеры:
– удалить таблицу DOC ;
– удалить таблицу ITEMS ;
– удалить таблицу BILLING_PERIOD со связанными данными в таблице PERIODS.
Важные замечания
- При выполнении действий по изменению структуры таблицы следует быть особенно осторожным, следует тщательно взвешивать свои действия: восстановление таблицы в прежнем виде может быть затруднительно или невозможно.
- Если вы используете команды изменения типов данных и встречаетесь с ошибкой ORA-01439 , модифицируемый столбец при смене типа данных должен быть пуст. Сохраните данные в столбце и используйте специальные преобразования, о которых будет рассказано в следующих шагах.
- В некоторых случаях удаление таблицы или колонки таблицы будет запрещено, поскольку могут быть еще таблицы со связанными данными. Требуется сначала удалить данные в связанных таблицах, а уже затем удалять таблицу либо колонку. Или же воспользоваться специальной командой DROP CASCADE.
Возможные вопросы
Да, вполне, и для этого есть две команды:
Универсальный же синтаксис предполагает использование ALTER TABLE .
Примеры:
Переименуем таблицу с названием STAFF в EMP:
Переименуем таблицу с названием TRADES в TRADE:
Можно ли переименовать столбец в таблице?
Да, синтаксис команды:
Пример:
Переименовать колонку с наименованием NAME в таблице STAFF в колонку LASTNAME :
Источник
Именование объектов в Oracle. Взгляд «со стороны»
«Старая песня о главном»
«Стандарты именование объектов БД» и «правила оформления кода» темы не новые. Так или иначе, к вопросу выработки или заимствования таких стандартов и правил приходят все команды разработчиков. При желании в сети можно найти статьи и презентации по данной теме, а так же примеры и шаблоны различных соглашений. Многие из них безусловно полезны, некоторые — практически идеальны, если бы не одна маленькая оговорка: они написаны разработчиками и для разработчиков.
К сожалению, в моей субъективной реальности разработчики являют собой лишь некую абстракцию. Эдакие фантомы по ту сторону телефонной трубки, от которых меня отделяют тысячи километров и 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.
В отдельный класс Коулэм выделяет таблицы, посредством которых реализуется взаимосвязь «многие-ко-многим». Для таких таблиц он предлагает следующий шаблон именования:
В большинстве проектов, с которыми я сталкивался, для таких таблиц-ассоциаций разработчики использовали «значащие» имена. Сам я использую шаблон:
Код таблицы в данном случае представляет собой сокращенное наименование таблицы, которая участвует в связке (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 символов на длину наименования. Поэтому стараюсь, где возможно использовать Код таблицы вместо полного имени. Таким образом, для первичного ключа получаем:
Здесь и далее префиксы Модуль и Группа ограничения получают в «наследство» от таблицы, с которой они связаны. Это позволяет избежать нарушений уникальности при формировании имен в больших системах, а так же удобно группировать ограничения по модулям.
Для уникального ключа, построенного на одном столбце:
Напоминаю, что шаблон столбца у нас включает Код таблицы. Таким образом, для колонки PRM_CODE таблицы UTL_PARAMS_REF уникальный ключ будет называться UTL_PRM_CODE_UK
Для уникального ключа, построенного на нескольких столбцах:
COMP – в данном случае обозначает COMPOSITE (признак составного ключа), # (порядковый номер) используется если уникальных составных ключей несколько (если честно, я не могу придумать вменяемый пример для такого случая).
Внешний ключ на базе одного столбца:
Так как полное наименование столбца внешнего ключа у нас содержит Коды дочерней и родительской таблиц, то для колонки PVL_PRM_ID таблицы UTL_PARAM_VALUES внешний ключ будет называться UTL_PVL_PRM_ID_FK (ссылается на столбец PRM_ID таблицы UTL_PARAMS_REF)
Внешний ключ, построенный на нескольких столбцах:
Ограничение на уровне столбца:
Ограничение на уровне таблицы:
На просторах Интернета я часто встречал горячие обсуждения необходимости именования ограничения типа NOT NULL. Да, согласен, лениво, но если строго придерживаться концепции, то:
Индексы
Индексы я обычно делю на три категории:
- Индексы на базе ключей (первичного и уникального)
- Индексы на базе одного столбца
- Составные (на базе нескольких столбцов)
Индексы на базе ключей (первичного и уникального) именуются так же, как и соответствующие им ограничения:
Индексы на базе одного столбца:
Под Ролью в данном шаблоне понимается модификатор типа индекса. Коулэм рекомендует использовать следующие модификаторы:
- L – локальный партицированный индекс
- G – Глобальный индекс на партицированной таблице
- B – Bitmap-индекс
- F – Индекс на основе функции
- C – compressed-индекс (сжатый)
- R – reverse key индекс (индекс с обратным порядком следования ключей)
- U – уникальный индекс
Индексы на основе нескольких столбцов. Коулэм рекомендует следующую форму:
Я считаю шаблон Коулэма частным случаем и всегда стараюсь перечислить все столбцы (если при этом не нарушается ограничение по длине) в наименовании индекса:
Почему я ограничиваюсь модификатором COMP для ограничений, но стараюсь не использовать его для индексов? Все дело в том, что составные ограничения все-таки являются скорее исключением, чем правилом. Их обычно не очень много, да и сообщение с ошибкой об их нарушении встречаются не очень часто. Другое дело – составные индексы. Во-первых, их просто много. Во-вторых, их часто больше одного на таблицу. И, в третьих, разработчик и администратор приложения работает с ними постоянно, проверяя планы запросов.
Триггеры
В данной статье я рассматриваю только триггеры DML, потому что считаю, что все остальные типы относятся больше к зоне ответственности DBA, а не разработчика. Триггеры я именую по следующим правилам:
Где аббревиатуры 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 и рекомендую именовать по следующему правилу:
Код таблицы (сокращенное наименование таблицы 2-4 символа) используется для последовательностей, служащих для генерации суррогатного первичного ключа таблицы.
Наименование столбца (а у нас оно, напомню, включает код таблицы) используется для генерации значения колонки, не входящей в первичный ключ. На самом деле, это вырожденный случай, который я реально не использую. Если последовательность не используется для генерации значений первичного ключа – в наименовании я стараюсь отразить Цель данной последовательности.
Для примера, последовательность для генерации первичного ключа таблицы INTERNET_LOGINS я назову ILG_SEQ, а последовательность для генерации логина конкретной учетной записи интернет – LOGIN_SEQ.
Синонимы
Синонимы именуются так же, как и объекты, на которые они ссылаются
По типам, у меня нет окончательно сформированного мнения. Я встречал разные подходы к именованию этих объектов, но так и не смог до конца определиться, какой подход мне ближе. Опишу здесь те, которые не вызывают во мне негативных реакций:
Данный шаблон рекомендует Коулэм. Признак коллекции типа обознается символом Т. Таким образом, тип одиночного объекта всегда имеет суффикс _T, тип коллекции — _TT. Например, UTL_PARAMETER_T, UTL_PARAMETER_TT.
Здесь S обозначает множественное число, а суффикс TYP квалифицирует объект БД как тип. Например, UTL_PARAMETER_TYP, UTL_PARAMETERS_TYP. Это подход мне нравится менее всего, потому что признак коллекции не выделен и глаз за него не цепляется.
В данной нотации, если наименование объекта БД заканчивается на OBJ или TAB, то объект является типом (TAB – коллекция, OBJ – одиночный объект). Например, UTL_PARAMETER_OBJ, UTL_PARAMETERS_TAB
Программные модули
Правила оформления кода программных модулей я хотел бы выделить отдельную статью. Здесь приведу шаблон, предлагаемый Коулэмом. Для пакетов процедур Билл использует следующее правило:
В терминах NC Коулэма Функциональный модификатор (для меня понятнее термин Подгруппа) используется при выделении каких-то функций в отдельный пакет при рефакторинге. Скажем так, это дополнительный уровень логической группы. Например, пакет UTIL содержал функции работы с числами и строками. Его разбили на два: UTIL_NUMBER и UTIL_STRING.
При разработке в PL/SQL специалист постоянно оперирует функциями и процедурами других пакетов. Чтобы код не смотрелся громоздким, я стараюсь избегать ненужного удлинения в наименовании пакетов. Поэтому суффикс _PKG использую только в случаях, когда наименование пакета может совпадать с наименованием другого объекта схемы.
Для отдельных процедур и функций Коулэм рекомендует следующий шаблон:
Под действием понимается глагол (GET, SET, ASSIGN, RUN), под целью – то, что необходимо сделать. Со своей стороны, я стараюсь вообще не использовать процедуры и функции вне пакетов при разработке. Кроме того, те же функции у меня часто группируются по объектам, с которыми они работают, поэтому я обычно использую шаблон
Таким образом, подсказчик кода отлично группирует процедуры по объектам: PARAM_GET, PARAM_SET, PARAM_CHECK и т.п.
Заключение
Как и обещал, привожу ссылку на собственный «Oracle NC»-плакат.
Я, ни в коем случае, не навязываю никому свои правила и стандарты и не настаиваю на их использовании. Я просто считаю наличие NC и соблюдение его требований в команде хорошим стилем — «вежливостью» разработчика к тому, кто будет работать впоследствии с системой.
Удачи вам в ваших проектах.
Источник