Меню

Sql правила именования таблица

Sql правила именования таблица

>> 2. Таблицы именуете в единственном числе или множественном?
В единственном числе

>> 3. Регистр: User vs user vs USER
user

>> 4. Названия из нескольких слов: UserMails vs user_mails
user_mail

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

автор
2. Таблицы именуете в единственном числе или множественном?
USER vs USERS

Во множественном

автор
3. Регистр: User vs user vs USER

users. Так глазу приятнее (моему)

автор
4. Названия из нескольких слов: UserMails vs user_mails

user_mails

Почему-то мне хочется использовать разные правила именования сущностей в SQL и в коде клиентского приложения. Так и делаю.

Названия из нескольких слов:
TblDocPayments

orunbek
Хранимки:
SP_.
SP_

Вот тут Селко спросит — а как будете избегать конфликта имен с системными процедурами в MS SQL?

не думаю что появится представление TblDocPayments, или же TblCommonJournal
поверил бы еще в TblUsers и TblUserSessions

1. Используете ли префиксы по модулям? — да
2. Таблицы именуете в единственном числе или множественном? — во множественном
3. Регистр: User vs user vs USER — только нижний
4. Названия из нескольких слов: UserMails vs user_mails — с подчеркиванием

Источник



Корпоративные хранилища данных. Интеграция систем. Проектная документация.

Правила именования объектов Oracle Database корпоративного хранилища данных

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

На данной странице представлены правила именования всех объектов базы данных корпоративного хранилища данных:

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

  • названия объектов должны быть ограничены 30 символами;
  • названия объектов не должны содержать пробелов;
  • описание объектов должно быть интуитивно понятно пользователю;
  • необходимо стараться давать максимально короткие имена с целью обеспечения хорошей управляемости;
  • при формировании имени объекта нужно быть уверенным, что оно не совпадает с внутренними объектами и командами, принятыми в Oracle.

Принятые сокращения

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

Термин Описание
V_ Обозначение переменной
V_G Обозначение глобальной переменной
V_P Обозначение переменной, являющейся параметром функции, процедуры, конструктора объектного типа, методах объектного типа
V_X Обозначение переменной, являющейся локальной в функции, процедуре, конструкторе объектного типа, методах объектного типа
T_ Обозначение объектного типа
WH Обозначение префикса табличного пространства, означающее принадлежность данного табличного пространства к корпоративному хранилищу данных
DICT Обозначение назначения табличного пространства, означающее тип хранимых данных — данные, имеющие отношение к нормативно-справочной информации
FACT Обозначение назначения табличного пространства, означающее тип хранимых данных — фактические значения показателей
MD Обозначение назначения табличного пространства, означающее тип хранимых данных — данные, содержащие описание структур и состава объектов корпоративного хранилища данных
WORK Обозначение назначения табличного пространства, означающее тип хранимых данных — промежуточные и рабочие данные, сырые и необработанные данные
DATA Обозначение типа табличного пространства, означающее характер хранимых данных – непосредственно данные
INDEX Обозначение типа табличного пространства, означающее характер хранимых данных – индексы
DBF Обозначение расширения файла данных, являющееся стандартом FA (Flexible Architecture) Oracle
DW$ Обозначение типа таблицы, пакета, означающее принадлежность к корпоративному хранилищу данных, а также для таблиц означает тип хранимых данных – данные нормативно-справочной информации
DWF$ Обозначение типа таблицы, пакета, означающее принадлежность к корпоративному хранилищу данных, а также для таблиц означает тип хранимых данных – фактически значения показателей
SYS$ Обозначение типа системных таблиц и системных пакетов, означающее принадлежность к корпоративному хранилищу данных. Данные объекты предназначены для описания структур, мониторинга и управления процессами
V$ Обозначение представлений, принадлежащих к корпоративному хранилищу данных
MV$ Обозначение материализованных представлений, принадлежащих к корпоративному хранилищу данных
PK Обозначение ограничения целостности класса Primary key
FK Обозначение ограничения целостности класса Foreign key
I Обозначение индекса
SEQ Обозначение поcледовательности, обеспечивающей генерацию уникальных ключей
KPI_ Префикс объектов, обеспечивающих поддержку функционирования подсистемы формирования отчетности по KPI
IAS_ Префикс объектов, обеспечивающих поддержку функционирования подсистемы формирования консолидированной финансовой отчетности по МСФО
BUD_ Префикс объектов, обеспечивающих поддержку функционирования подсистемы бюджетного управления
MGR_ Префикс объектов, обеспечивающих поддержку функционирования подсистемы формирования управленческой отчетности
_SERVICE Суффикс добавляемый к названию пакета, определяющий что данный программный код является пакетом функций и процедур внутренней логики функционирования процессов корпоративного хранилища данных

Правила именования табличных пространств и файлов данных

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

Не допускается наличие пробелов в названии табличных пространств.

При формировании названия табличного пространства необходимо руководствоваться составным кодом: Префикс_Назначение_Тип, где различные элементы значения разделены символом разделителя «_».

Читайте также:  Объем стопы таблица размеров

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

Для каждого создаваемого табличного пространства должен быть установлен соответствующий префикс – «WH». Это необходимо, помимо обеспечения прозрачности проектирования и сопровождения системы, для обеспечения удобства администрирования базой данных.

В качестве назначения табличного пространства допускаются следующие значения: «DICT», «FACT», «MD», «WORK».

В качестве типа табличного пространства допускаются следующие значения: «DATA», «INDEX».

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

Название таблиц может содержать набор вплоть до 30 латинских символов. Названия должны быть уникальны.

Не допускается наличие пробелов в названии таблиц.

Таблицы корпоративного хранилища данных делятся на следующие четыре класса:

  1. Таблицы метаданных внедряемого программного обеспечения.
  2. Системные таблицы, обеспечивающие мониторинг и функционирование основных процессов.
  3. Таблицы, содержащие элементы нормативно-справочной информации.
  4. Таблицы, содержащие фактические значения показателей корпоративного хранилища данных.

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

При формировании названия таблиц регулируемых классов (2-4) необходимо руководствоваться составным кодом: [Префикс]_Тип_Название, где различные элементы значения разделены символом разделителя «_». При этом наличие префикса является опциональным и предполагается для объектов, поддерживающих непосредственно функционирование бизнес подсистем.

В качестве префикса таблиц допускаются следующие значения: «KPI», «IAS», «BUD», «MGR».

В качестве типа таблиц допускаются следующие значения: «SYS$», «DW$», «DWH$».

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

Правила именования ограничений целостности

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

Не допускается наличие пробелов в названии ограничений целостности.

При формировании названия ограничений целостности необходимо руководствоваться составным кодом: Имя базовой таблицы_Тип, где различные элементы значения разделены символом разделителя «_».

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

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

В качестве типа допускаются следующие значения: «PK», «FK».

Правила именования индексов

Название индексов может содержать набор вплоть до 30 латинских символов. Названия должны быть уникальны.

Не допускается наличие пробелов в названии индексов.

При формировании названия индекса необходимо руководствоваться составным кодом: Имя базовой таблицы_Суффикс, где различные элементы значения разделены символом разделителя «_».

Множество значений в рамках указанного алгоритма достигается за счет добавления нумерации к суффиксу индекса.

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

В качестве суффикса допускаются следующие значения: «I».

Правила именования программных пакетов

Название программных пакетов может содержать набор вплоть до 30 латинских символов. Названия должны быть уникальны.

Не допускается наличие пробелов в названии программных пакетов.

Программные пакеты корпоративного хранилища данных делятся на следующие четыре класса:

  1. Программные пакеты метаданных внедряемого программного обеспечения.
  2. Программные пакеты, генерируемые программным обеспечением автоматически.
  3. Системные программные пакеты, обеспечивающие мониторинг и функционирование основных процессов.
  4. Программные пакеты, обеспечивающие функционирование подсистем.

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

При формировании названия программных пакетов регулируемых классов (3-4) необходимо руководствоваться составным кодом: [Префикс]_Тип_Название_Суффикс, где различные элементы значения разделены символом разделителя «_». При этом наличие префикса является опциональным и предполагается для объектов, поддерживающих непосредственно функционирование бизнес подсистем.

В качестве префикса программных пакетов допускаются следующие значения: «KPI», «IAS», «BUD», «MGR».

В качестве типа программных пакетов допускаются следующие значения: «SYS$», «DW$».

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

В качестве суффикса программных пакетов допускаются следующие значения: «SERVICE».

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

Название объектных типов может содержать набор вплоть до 30 латинских символов. Названия должны быть уникальны.

Не допускается наличие пробелов в названии объектных типов.

Объектные типы корпоративного хранилища данных делятся на следующие три класса:

  1. Объектные типы метаданных внедряемого программного обеспечения.
  2. Системные объектные типы, обеспечивающие мониторинг и функционирование основных процессов.
  3. Объектные типы, обеспечивающие функционирование подсистем.

Наименование объектных типов метаданных определяется регламентами непосредственно программного обеспечения и не предполагает вмешательства консультантов.

При формировании названия объектных типов регулируемых классов (2-3) необходимо руководствоваться составным кодом: [Префикс]_Тип_Название, где различные элементы значения разделены символом разделителя «_». При этом наличие префикса является опциональным и предполагается для объектов, поддерживающих непосредственно функционирование бизнес подсистем.

В качестве префикса объектных типов допускаются следующие значения: «KPI», «IAS», «BUD», «MGR».

В качестве типа объектных типов допускаются следующие значения: «T».

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

Читайте также:  Сколько весит куб песка строительного кг м3 таблица

Правила именования представлений

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

Не допускается наличие пробелов в названии представлений.

Представления корпоративного хранилища данных делятся на следующие три класса:

  1. Представления метаданных внедряемого программного обеспечения.
  2. Системные представления, обеспечивающие мониторинг и функционирование основных процессов.
  3. Представления, обеспечивающие функционирование подсистем.

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

При формировании названия представлений регулируемых классов (2-3) необходимо руководствоваться составным кодом: [Префикс]_Тип_Название, где различные элементы значения разделены символом разделителя «_». При этом наличие префикса является опциональным и предполагается для объектов, поддерживающих непосредственно функционирование бизнес подсистем.

В качестве префикса представлений допускаются следующие значения: «KPI», «IAS», «BUD», «MGR».

В качестве типа представлений допускаются следующие значения: «V$».

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

Правила именования материализованных представлений

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

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

Материализованные представления корпоративного хранилища данных делятся на следующие три класса:

  1. Материализованные представления метаданных внедряемого программного обеспечения.
  2. Системные материализованные представления, обеспечивающие мониторинг и функционирование основных процессов.
  3. Материализованные представления, обеспечивающие функционирование подсистем.

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

При формировании названия материализованных представлений регулируемых классов (2-3) необходимо руководствоваться составным кодом: [Префикс]_Тип_Название, где различные элементы значения разделены символом разделителя «_». При этом наличие префикса является опциональным и предполагается для объектов, поддерживающих непосредственно функционирование бизнес подсистем.

В качестве префикса материализованных представлений допускаются следующие значения: «KPI», «IAS», «BUD», «MGR».

В качестве типа материализованных представлений допускаются следующие значения: «MV$».

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

Правила именования последовательностей

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

Не допускается наличие пробелов в названии последовательностей.

При формировании названия последовательности необходимо руководствоваться составным кодом: [Префикс]_Тип_Название_Суффикс, где различные элементы значения разделены символом разделителя «_».При этом наличие префикса является опциональным и предполагается для объектов, поддерживающих непосредственно функционирование бизнес подсистем.

В качестве префикса последовательностей допускаются следующие значения: «KPI», «IAS», «BUD», «MGR».

В качестве типа последовательностей допускаются следующие значения: «DW$».

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

В качестве суффикса допускаются следующие значения: «SEQ».

Правила именования имен переменных в программных блоках PL-SQL

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

Не допускается наличие пробелов в названии переменных.

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

  1. Глобальные переменные.
  2. Переменные, являющиеся параметрами процедур, функций, методов объектных типов.
  3. Локальные переменные.

При формировании названия переменной необходимо руководствоваться составным кодом: [Префикс]_Тип_Название, где различные элементы значения разделены символом разделителя «_».

В качестве префикса переменной допускаются следующие значения: «V».

В качестве типа переменной допускаются следующие значения: «G», «P», «X».

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

Источник

SQL — рекомендации именования

Придерживаться правил именования при разработке , всегда является хоршим тоном, поэтому, мне кажется, в SQL такие правила тоже должны быть.

1. НАИМЕНОВАНИЯ ТАБЛИЦ.

Именование таблиц должно подчиняться следующим правилам:
Имена таблиц не имеющие родительской таблицы == «Составное строчное имя» отражающее содержимое таблицы.
Пример:

  • еnterprise (юридические лица);
  • сlient (Корреспонденты);
  • people (физические лица);

Имена дочерних таблиц == имя родительской таблицы + имя дочерней таблицы, разделенные символом подчеркивания. Под «дочерней» понимается такая таблица, из которой, при удалении записи в родительской таблице, удаляются все записи имеющие ссылку на удаляемую запись в родительской таблице.

  • client_account (Счета корреспондентов);
  • client_personnel (Сотрудники корреспондентов)

Имена дочерних таблиц, имеющих строчную часть, но не имеющих собственного имени, формируются из имени родительской таблицы + постфикс “_row”.

  • credit (Документ «Кредиты»);
  • credit_row (Строчная часть документа);
  • credit_penalty (Пени по кредиту);
  • credit_percent (Проценты по кредиту)
Читайте также:  Что значит таблица квадратов

2. НАИМЕНОВАНИЯ ПОЛЕЙ ТАБЛИЦ.

Именование полей таблицы должно подчиняться следующим правилам:

  • «Имя поля простого типа» — «Составное строчное имя» отражающее содержимое поля.
  • «Имя поля ссылочного типа» == наименование таблицы, на которую ссылается данное поле + постфикс «_id». Исключение составляют случаи, когда есть несколько ссылок на одну и ту же таблицу. В этом случае имя поля формируется как «Имя поля простого типа» + постфикс «_id».
  • Поля типа «tinyint», принимающие значения 1 или 0 == префикс «flag_» + «Составное строчное имя». «Составное строчное имя» должно отражать содержимое поля, при состоянии флага равному 1.
  • client_id (ссылка на таблицу корреспондентов);
  • tax_client_id, estim_client_id (ссылки на таблицу корреспондентов «Client», налогоплательщик, распорядитель сметы);
  • flag_confirm (флаг 1 = утвержден, 0 = не утвержден);
  • comment (комментарий)

Перечень имен полей для обязательного использования, при совпадении назначения полей в таблице.

  • comment — комментарий
  • name — краткое наименование
  • short_name — сокращенное наименование (псевдоним)
  • full_name — полное наименование
  • doc_date — дата документа
  • doc_num — номер документа
  • doc_status — состояние документа
  • date_set — дата утверждения документа
  • date_start — дата начала
  • date_end — дата конца
  • date_update — дата обновления
  • guid — глобальный уникальный идентификатор
  • summa — сумма
  • amount — количество
  • rate — ставка
  • mult — коэффициент

Перечень зарезервированных имен.

  • id;
  • owner_id.

Любая таблица должна иметь первичный ключ — автоинкрементное поле с именем «id».
Дочерняя таблица должна иметь поле с именем owner_id, внешним ключом (с ограничением целостности «On Delete = Cascade») должна быть связана с родительской таблицей (с полем id).

3. НАИМЕНОВАНИЯ ИНДЕКСОВ.

Именование индексов таблицы должно подчиняться следующим правилам:

«Имя индекса» == «Префикс индекса» + «_» + наименование таблицы + «$» + перечисление имен полей таблицы, участвующих в построении индекса, разделенных символом “$”.

«Префик индекса» может принимать одно из следующих значений:

  • in == обычный индекс;
  • iu == уникальный индекс.

iu_credit_penalty$owner_id$doc_num (уникальный индекс в таблице «credit_penalty» по полям «owner_id» + «doc_num»)

4. НАИМЕНОВАНИЯ ОГРАНИЧЕНИЙ ЦЕЛОСТНОСТИ.

Именование ограничения целостности таблицы должно подчиняться следующим правилам: «Ограничение целостности» == «Префикс ограничения целостности» + «_» + наименование таблицы + «$» + пречисление имен полей таблицы, участвующих в построении индекса, разделенных символом “$”. «Префикс ограничения целостности» может принимать одно из следующих значений:

  • pk == PRIMARY KEY
  • fk == FOREIGN KEY
  • ck == CHECK
  • uk == UNIQUE
  • dk == DEFAULT

Например внешний ключ:

fk _ User__ id ____ Comment__ userId

Сформирован по формуле:

fk_ + ИмяВнешнейТаблицы [__ИмяПоляВнешнейТаблицы] + ____ + ИмяТекущейТаблицы [__ ИмяПоляТекущейТаблицы[__ . ]]

Приведенный выше пример может быть аналогичен следующему:

но только, если является единственным по отношению к Внешней таблице.

5. НАИМЕНОВАНИЯ ТРИГГЕРОВ ТАБЛИЦ.

Именование триггера таблицы должно подчиняться следующим правилам: «Имя триггера» == “t” + «Префикс типа триггера» + «_» + наименование таблицы. «Префикс типа триггера» может иметь длину от двух до четырех символов.

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

  • a == «after» триггер, срабатывает после обработки SQL-сервером события;
  • b == «before» триггер, срабатывает перед обработкой SQL-сервером события;
  • i == «instead of» триггер, заменяет собой действия SQL-сервера по обработке события.

Второй и (для комбинированного триггера) последующие символы — это комбинация в алфавитном порядке следующих символов:

  • d == «delete» триггер;
  • i == «insert» триггер;
  • u == «update» триггер.
  • Выносить избыточную логику из триггеров в хранимые процедуры.
  • Не формировать каскады триггеров, подписанных на одно событие.
  • Не формировать триггера, функционально аналогичные ограничениям целостности.
  • tai_client («after-insert» триггер по таблице «client»);
  • tbu_client («before-update» триггер по таблице «client»);
  • tadiu_client («after-delete, insert, update» триггер по таблице «client»)

Источник

Sql правила именования таблица

>> 2. Таблицы именуете в единственном числе или множественном?
В единственном числе

>> 3. Регистр: User vs user vs USER
user

>> 4. Названия из нескольких слов: UserMails vs user_mails
user_mail

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

автор
2. Таблицы именуете в единственном числе или множественном?
USER vs USERS

Во множественном

автор
3. Регистр: User vs user vs USER

users. Так глазу приятнее (моему)

автор
4. Названия из нескольких слов: UserMails vs user_mails

user_mails

Почему-то мне хочется использовать разные правила именования сущностей в SQL и в коде клиентского приложения. Так и делаю.

Названия из нескольких слов:
TblDocPayments

orunbek
Хранимки:
SP_.
SP_

Вот тут Селко спросит — а как будете избегать конфликта имен с системными процедурами в MS SQL?

не думаю что появится представление TblDocPayments, или же TblCommonJournal
поверил бы еще в TblUsers и TblUserSessions

1. Используете ли префиксы по модулям? — да
2. Таблицы именуете в единственном числе или множественном? — во множественном
3. Регистр: User vs user vs USER — только нижний
4. Названия из нескольких слов: UserMails vs user_mails — с подчеркиванием

Источник

Adblock
detector