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

02.06.2021

О чем эта статья

Эта статья продолжает цикл статей «Первые шаги в разработке на 1С». В ней рассматриваются принципы работы с универсальными коллекциями. Прочитав статью, вы узнаете:

Что такое универсальные коллекции, когда и в каких случаях их необходимо использовать?
Что общего у всех универсальных коллекций? Какие приемы можно использовать для работы со всеми ними?
Что такое массив, как и когда его использовать? Какие у него есть методы?
Зачем использовать структуру? В чем её отличие от массива?
В каких случаях использовать список значений? Как отобразить его на форме?
Соответствие – что это и когда его использовать? В чем преимущества относительно структуры?
Для чего используется таблица значений? Как описать ее структуру? Как добавить/удалить строки? Как вывести ее на форму?
Дерево значений – для чего используется? Как заполнить и вывести на форму? Как с ним работать?

Применимость

В статье рассматривается платформа 1С:Предприятие 8.3 актуальной редакции.

Как в 1С работать с универсальными коллекциями

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

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

Важно понимать, что коллекции не хранятся в базе данных (о типе данных Хранилище значений, которое может сохранять практически любой тип данных, речь пока не идет).

Существуют различные виды универсальных коллекций: Массив, Структура, Соответствие, Фиксированный массив, Таблица значений, Табличная часть и т.д. Но у всех коллекций есть схожесть поведения.

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

Можно получить новую коллекцию вручную, обратившись к конструктору и создав экземпляр класса.

Например: НашМассив = Новый Массив;

Конструкторы для многих универсальных коллекций являются параметризованными.

Так, в конструкторе для можно указать количество элементов в соответствующих измерениях. Т.е. можно сразу же объявлять многомерные .

Соответствующее описание конструктора есть в синтакс-помощнике.

Таким образом, используя параметры конструктора, можно сразу задать желаемое поведение данного объекта.

Но параметры являются необязательными, разработчик может их не задавать и в дальнейшем определить поведение Массива так, как считает нужным.

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

Для универсальных коллекций существуют такие общие понятия, как индекс и номер. Каждый элемент коллекции имеет индекс. При этом индекс начинается с нуля.

Для того чтобы обратиться к элементу НашМассив , можно использовать обращение по индексу, для этого индекс указывается в квадратных скобках.

Например, НашМассив . Обратите внимание, в этом случае система возвращает элемент Массива с индексом 3, а по порядку это четвертый элемент Массива.

Для некоторых коллекций существует также понятие номера строки. Номер строки начинается с единицы. Например, для табличной части есть такое свойство, как номер строки. Важно иметь ввиду, что если мы знаем номер строки и хотим обратиться по индексу, то в качестве индекса следует использовать значение на единицу меньше номера строки.

Понятие номера строки существует далеко не у всех коллекций, а преимущественно у тех, которые могут отображаться в интерфейсе пользователя.

Для всех коллекций используется обход элементов коллекции. Обход возможен двумя способами: циклом Для и циклом Для каждого из .

Для большинства универсальных коллекций применимы методы: Количество, Индекс, Добавить, Вставить, Удалить и Найти.

Количество – это функция, которая возвращает количество элементов коллекции. Она может использоваться перед циклом Для , как представлено на рисунке.

Метод Индекс существует не у всех коллекций, а только у тех, на элементы которой можно сослаться. В качестве примера можно привести ТаблицуЗначений .

ТаблицаЗначений – это определенная коллекция строк, в строках могут содержаться разные колонки с разными типами значений.

Каждая строка представляет собой самостоятельную сущность. На нее можно получить ссылку, через эту строку можно обращаться к значениям колонок в данной строке.

Метод Индекс позволяет определить, какой индекс соответствует данной строке (т.е. текущую позицию строки в таблице). Значения индекса начинаются с нуля.

Методы добавления новых значений в данную коллекцию существуют практически у любой универсальной коллекции. На рисунке представлено, как заполнить Массив значениями от 0 до 10 двумя способами.

Для того, чтобы добавить элемент в Массив мы можем использовать метод Добавить , в скобках указать добавляемое значение. При этом значение будет добавляться в конец списка, т.е. Массив будет постоянно увеличиваться за счет последней позиции.

Другой метод, который позволяет добавлять значения в коллекцию – метод Вставить . Он отличается от метода Добавить тем, что можно указать, в какое место нужно вставить добавляемый элемент.

Синтаксис: Вставить (,)

Первым параметром указывается индекс, в который будет вставлено новое значение. Т.е. мы, например, можем указать, что каждое значение нужно вставлять в начало списка (второй способ на рисунке выше).

Для удаления элементов из коллекции используется метод Удалить . В методе Удалить указывается по индексу, какой элемент мы будем удалять.

Синтаксис: Удалить()
Пример использования: НашМассив.Удалить(5);

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

Практически у всех коллекций существует метод поиска значения – Найти . В метод передается то значение, которое хотим найти. В некоторых коллекциях можно поставить какие-либо ограничения.

Например, в ТаблицеЗначений можно указать те строки, те колонки, в которых нужно осуществлять поиск.

Если значение найдено, то данный метод возвращает индекс или определенную строку. Если значение не найдено, возвращается значение типа Неопределено . Применительно к Массиву возвращается Индекс , либо значение Неопределено .

Пример использования: НашаПеременная = НашМассив.Найти(8);

Универсальные коллекции можно очень быстро очищать, т.е. удалить абсолютно все элементы. Для этого используется метод Очистить() , который удаляет элементы Массива, строки ТаблицыЗначений , либо данные других коллекций.

Дополнительные методы для Массива

Метод ВГраница() возвращает количество элементов минус один. Т.е. если мы используем цикл Для , то вместо метода Количество можем сразу использовать метод Граница() .

В частности, переменную КоличествоВМассиве можно было определить иначе:

КоличествоВМассиве = НашМассив.ВГраница();
Тогда при описании самого цикла отнимать от данной переменной единицу не следует.

Метод Установить позволяет присвоить значение элементу Массива по индексу.

Синтаксис: Установить(,)

Пример: НашМассив.Установить (2,8);

Альтернативный вариант: НашМассив = 8;

Можно для Массива использовать метод Получить , для того, чтобы прочитать значение по индексу, не обращаясь к использованию квадратных скобок.

Синтаксис: Получить()

Пример: НашаПеременная = НашМассив.Получить(2);

Альтернативный вариант: НашаПеременная = НашМассив;

Универсальная коллекция Структура

Структура, так же как и Массив, может иметь неограниченное количество элементов, но вот содержание элемента отличается от Массива.

Структура представляет собой коллекцию, каждое значение которой состоит из пары. Первый элемент пары называется Ключ . Второй элемент пары – Значение .

Ключ – это строго строковый тип данных, который описывает значение. Например, Ключу «Код» может соответствовать значение 113; Ключу «Имя» значение «Вася». На само Значение ограничение типа данных не накладывается.

Структуру очень удобно использовать, если мы хотим создать некий список параметров. Если данная Структура называется НашаСтруктура , то обращаться к ее двум значениям мы будем следующим образом: НашаСтруктура.Код и НашаСтруктура.Имя.

Такое обращение гораздо удобнее, чем если бы мы все параметры определили в Массив и обращались к ним по индексу.

Структура делает программный код читаемым (понятным). Структура применяется достаточно часто, гораздо чаще чем Массив.

Она используется для описания некоторых параметров, которых зачастую существует достаточно большое количество во всех алгоритмах.

Кроме того, Структура применяется в том случае, если процедура и функция содержат большое количество передаваемых параметров.

Тогда гораздо удобнее записать все параметры в Структуру и именно ее и передавать. Т.е. происходит «упаковка» параметров процедур и функций.

Отдельно следует отметить, что в качестве Ключа в Структуре может выступать не абсолютно любая строка. Накладываются определенные ограничения.

Ключ должен выступать в качестве идентификатора. Это означает, что в Ключе не должно быть пробелов и он не может начинаться с цифры.

Допустимо начало Ключа с буквы или знака подчеркивания. Таким образом, Ключ должен удовлетворять требованиям к созданию идентификаторов.

Отметим, чем еще Сруктура отличается от Массива. В Структуре есть метод Вставить , в Массиве есть два метода для вставки: Вставить (в определенную позицию) и Добавить (в конец списка). В Массиве все элементы являются упорядоченными.

Структура – это некое неупорядоченное множество. Именно поэтому для Структуры существует только метод вставки.

Значение вставляется не на конкретную позицию, а в указанное множество. Для Структуры недопустимо обращение по индексу, как для других универсальных коллекций.

К элементам Структуры обращаются только по имени Ключа. Тем не менее, цикл Для каждого из работает и для Структуры, но опираться на порядок элементов Структуры не следует.

Структура создается точно так же, как и другие универсальные коллекции с помощью использования конструктора Новый, указывая тип данных Структура.

Как и Массив, конструктор Структуры может иметь параметры. Т.е. возможно описать само содержание Структуры, используя конструктор.

В отличие от Массива, где можно просто указать количество элементов для всех размерностей, в Структуре возможно задавать само содержание.

Например: НашаСтруктура = Новый Структура (“Код,Имя”, 133, “Вася”);

Через запятую перечисляются сначала имена Ключей, а потом, соответственно, в той же последовательности значения параметров.

Для добавления в Структуру нового значения существует метод Вставить , который вставляет новую пару (Ключ и Значение).

Например: НашаСтруктура.Вставить(“ЧленовСемьи”,3);

Для Структуры характерен еще один метод, который используется достаточно часто. Это метод Свойство .

С помощью данного метода можно понять, а есть ли в этой Структуре такой элемент, у которого Ключ имеет такое-то имя.

Если существует такой элемент, то система вернет значение Истина, в противном случае – Ложь.

Например, выражение НашаСтруктура.Свойство (“ЧленовСемьи”) будет равно значению Истина. Этот метод применяется достаточно часто при анализе Структуры.

Как и для любой универсальной коллекции, допустимо обращение к свойствам Структуры по индексу. Но индекс для Структуры – это строковое значение.

Например: Сообщить(НашаСтруктура[“ЧленовСемьи”]);

Однако следует не забывать, что Структура – это не упорядоченное множество объектов, именно поэтому обращение по индексу 0, 1, 2 недопустимо.

Универсальная коллекция Список значений

СписокЗначений представляет собой линейный список элементов любого типа данных.

Каждый элемент состоит из нескольких значений. Схематично список значений можно представить в виде списка с четырьмя колонками.

Первая колонка – Отметка . Она имеет булевский тип данных и позволяет пользователю либо ставить флажки, либо их снимать.

Другая колонка – это картинка, которая может каким-то образом визуально изображать данный элемент, т.е. ставить в соответствие данной строке какую-либо картинку.

Третья колонка – само хранимое значение, т.е. это любой тип данных, причем в разных строках он может быть различным.

Четвертая колонка – это представление, т.е. это некое строковое описание данного значения. Представление будет выводиться пользователю, когда он будет просматривать данный элемент. При этом, если представление не задано, система будет пытаться сама получить представления для элемента, содержащегося в данной позиции.

СписокЗначений – это тот объект, с которым может визуально работать пользователь. Т.е. СписокЗначений можно вывести на форму.

Пользователь может выполнять с ним какие-то действия. Кроме этого, СписокЗначений можно вывести независимо, используя методы, т.е. показать на экран в некоторой ветке алгоритма (за исключением серверного кода), чтобы пользователь выбрал какую-то строчку или проставил какие-либо галочки.

Найдем СписокЗначений в ситакс-помощнике. Конструктор СпискаЗначений не параметризованный (нельзя задать какие-то значения по умолчанию).

Есть такие методы, как:

Вставить(,) ;
Добавить(,);
Количество();
Индекс().

Есть и специальные методы, например, ВыгрузитьЗначения() . При этом создается Массив, в который копируется список значений. Например:

МассивЭлементов = СписокТиповЦен.ВызрузитьЗначения();

Существует и обратный метод:
СписокТиповЦен.ЗагрузитьЗначения(МассивЭлементов);

Существуют методы поиска:
НайтиПоЗначению(); НайтиПоИдентификатору().

Есть метод копирования:
КопияСписка = СписокТиповЦен.Скопировать();
Данный метод предназначен для того, чтобы сделать какую-то модификацию с копией.

Существуют методы:
СортироватьПоЗначению();
СортироватьПоПредставлению().

Методы ВыбратьЭлемент(,) и ОтметитьЭлементы () вызывают модальное диалоговое окно, которое останавливает выполнение алгоритма, пока пользователь не закроет данное окно.

Для использования этих методов в свойствах конфигурации Режим использования модальности должен быть установлен на значение Использовать .

Пример кода, вызываемого из модуля Управляемого приложения:

Отображение данного кода в пользовательском режиме (модальное диалоговое окно).

Ниже СписокЗначений используется в качестве доступного типа данных для реквизита формы. Создаем для формы обработки новый реквизит, определяем для него тип СписокЗначений и отображаем его на форме.

Создаем новую команду ЗапонитьПодарки , переносим на форму и определяем для нее обработчик действия.

В пользовательском режиме, при нажатии в форме обработки кнопки Заполнить подарки, появится заполненный список.

При желании список можно редактировать: какие-то элементы добавить, какие-то – удалить.

Универсальная коллекция Соответствие

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

Главное отличие в том, что в качестве Ключа может указываться любой тип данных, равно как и для значения. В виду этой особенности обращаться к значению соответствия необходимо по индексу, в качестве значения индекса указывается значение ключа.

В качестве ключа может быть тип данных, отличающихся от строки. Свойства и методы работы с Соответствием практически такие же, как у Структуры.

Конструктор Соответствия, в отличии от Структуры, не содержит возможности указания параметров.

Пример использования:

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

При вставке элементов в коллекцию Соответствие помимо метода Вставить(,) существует другой способ вставки значения – это использование обычного оператора присваивания.

Например: НашеСоответствие = Новый Соответствие;
Соответствие = 999;

Т.е. если элемент в коллекции не присутствовал, то с помощью оператора присваивания он будет добавлен, а если присутствовал, то будет обновлен.

Это является отличием от Структуры.

Универсальная коллекция Таблица значений

ТаблицаЗначений представляет из себя таблицу с произвольным количеством строк и произвольным количеством колонок. На пересечении могут храниться значения любого типа данных. При необходимости колонки можно типизировать, т. е. определить в какой колонке какой тип данных хранится.

Можно оставить колонки нетипизированными, тогда в одной колонке в разных строках могут храниться значения разных типов.

Отличия ТаблицыЗначений от двухмерного Массива:

это объект, с которым может работать пользователь (таблицу значений можно вывести на экран, пользователь может ее заполнять, в дальнейшем введенные данные можно читать);
построение индексов для быстрого поиска;
клонирование, заполнение определенным значением всей колонки, выгрузка все колонки в массив.

ТаблицаЗначений используется как некий буфер хранения информации. ТаблицаЗначений возвращается и принимается как параметр многими методами системы. К Таблице значений возможно построить запрос.

Итак, ТаблицаЗначений состоит из набора строк и набора колонок. И строки, и колонки представляют собой коллекции.

Т.е. внутри коллекции ТаблицаЗначений есть еще две коллекции. Обратимся к синтакс-помощнику и найдем ТаблицуЗначений .

Поддерживаемые типы данных: сама ТаблицаЗначений , которая состоит из строк. Каждая строка представлена типом данных СтрокаТаблицыЗначений , у которой есть свои свойства и свои методы. Имеется КоллекцияКолонок ТаблицыЗначений также обладает определенными свойствами.

Важный момент! Процедура, которая формирует ТаблицуЗначений , должна компилироваться & НаСервере.

Прежде, чем начать работать с ТаблицейЗначений , необходимо определить, какие в ней будут содержаться колонки (т.е. создать их). Синтаксис:

Добавить(,)
(необязательный)
Тип: Строка.
(необязательный)
Тип: ОписаниеТипов
(необязательный)
Тип: Строка.
(необязательный)
Тип: Число.

Например:

Для вызова данной процедуры будем использовать команду.

В описании ТаблицыЗначений в качестве элементов коллекции выступают именно СтрокиТаблицыЗначений .

В отличии от колонок, которые состоят только из свойств (Имя, Тип, Заголовок, Ширина), в СтрокеТаблицыЗначений существуют как свойства (обращение по имени колонки), так и методы (можно получать и устанавливать значение, работать с владельцами).

Чтобы добавить новую строку в таблицу нужно использовать метод либо Добавить() , либо Вставить() . Во втором случае следует указать, на какую позицию нужно выставлять требуемую строку.

Чтобы присвоить значение колонке, мы через точку обращаемся по имени колонки или по индексу (с помощью квадратных скобок).

Для заполнения ТаблицыЗначений могут использоваться следующие методы:

Очистить() – для удаления всех строк из ТаблицыЗначений .

ЗаполнитьЗначения(,) – позволяет заполнить все колонки, либо выбранные колонки одним значением.
ЗагрузитьКолонку(,) – загружает колонку из массива.
ВыгрузитьКолонку() – выгружает колонку в массив.

Два последних метода удобно использовать, когда нужно перебросить колонку из одной таблицы значений в другую.

Скопировать(,) – позволяет на основании существующей таблицы создать новую ТаблицуЗначений , при этом указывать не все строки и все колонки, а только некоторые из них. Возвращаемое значение – ТаблицаЗначений .

Можно скопировать структуру ТаблицыЗначений . Для этого существует соответствующий метод СкопироватьКолонки() . Мы получим пустую ТаблицуЗначений с требуемой структурой.

В ТаблицеЗначений существует метод Итог() . Можно указать ту колонку, в которой нужно просуммировать числовые величины. Применительно к ранее показанному коду в Табло можно рассчитать значение: ТЗ.Итог(“Сумма”) .

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

Применительно к ранее показанному коду в Табло можно рассчитать значение: ТЗ.Свернуть(“ДеньНедели”,“Сумма”).

ТаблицуЗначений можно показать на пользовательском экране, чтобы с ней можно было совершать какие-либо действия. Но в отличии от СпискаЗначений из программного кода нельзя просто так вызвать таблицу на экран.

Чтобы отобразить ТаблицуЗначений на экране, создадим реквизит формы и присвоим ему тип данных ТаблицаЗначений .

После чего полученную таблицу следует вывести на форму.

В модуле формы в конце ранее составленного алгоритма (в Процедуре СозданиеТаблицыЗначений) следует дописать:
ЗначениеВДанныеФормы(ТЗ, Таблица);

Универсальная коллекция Дерево значений

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

Тоже может быть отражено на экране. Дерево значений в явном виде состоит из коллекции строк и коллекции колонок. В дереве существуют такие два свойства как Строки и Колонки.

Поскольку строки могут быть подчинены друг другу, то для каждой строки может быть указан Родитель, а также подчиненные ей строки.

Создадим соответствующую команду Дерево и ее процедуру обработки.

Создадим в котором одна родительская строка и две подчиненные.

Создадим реквизит формы ДерЗн (тип данных – ДеревоЗначений).

Для этого реквизита создадим колонки Год и Месяц.

Переместим соответствующий элемент ДерЗн на форму.

В конце Процедуры ДеревоНаСервере() допишем:

ЗначениеВДанныеФормы(ДеревоЗн, ДерЗн);

Проверим, что получилось в пользовательском режиме.

С помощью кнопки Добавить можно добавлять новые строки. Они могут также образовывать иерархию.

Чтобы обойти все элементы дерева значений, нам понадобится использовать рекурсию, т.е. вызов процедуры самой из себя. Например, обработка дерева значений может выглядеть так:

На этом мы завершаем наше первое знакомство с универсальными коллекциями.

В следующей статье рассмотрим, при помощи какого важного механизма разработчик может упростить обращение к элементу справочника из программного кода.

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

К сожалению, в моей субъективной реальности разработчики являют собой лишь некую абстракцию. Эдакие фантомы по ту сторону телефонной трубки, от которых меня отделяют тысячи километров и 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-плаката и отредактировать его под свои цели и задачи.

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