Разработайте строгие правила использования прописных букв

Обоснование
Правила работы с регистрами различны в разных продуктах. В стандартном SQL, а также продуктах IBM и Oracle обычные идентификаторы переводятся в верхний регистр, а регистр идентификаторов в кавычках остается неизменным. В продуктах Microsoft правила использования регистров определяются не типом идентификатора, а заданным умолчанием. По умолчанию регистры не различаются, то есть “t” равно “Т”.
С распознаванием регистров связаны две проблемы. Во-первых, согласно стандарту SQL, идентификатор в кавычках "t" и обычный идентификатор t различаются. Во-вторых, Microsoft не следует стандарту SQL. Поэтому трудно придумать правило построения имен, которое подошло бы всем.

Исключения
Я предложу вам простой набор правил, основанный на принципах читаемости и эстетичности, вовсе не претендуя на его единственность.
1. Не используйте идентификаторы с ограничителями.
2. В IBM используется только верхний регистр. К сожалению, код в верхнем регистре трудно читать. Кроме того, у читателя возникнет подозрение, что вы до сих пор работаете с перфокартами.
3. В Microsoft и Oracle нижний регистр используется везде, где он уместен. К сожалению, определение уместности не всегда оказывается вполнечетким. Часть зарезервированных слов набирается в верхнем регистре, часть — в нижнем и т.д.

Создавайте имена согласно стандарту ISO-11179

Это относительно новый стандарт ISO для метаданных, и понятен он пока далеко не всем. К счастью, те его правила, которые нужны программисту SQL, просты и очевидны. Настоящая проблема в том, что многие люди нарушают эти правила. В сокращенном виде правила для элементов данных, разработанные комитетом стандартов метаданных NCITS L8, опубликованы на следующих сайтах:

http://pueblo.lbl.gov/~olken/X3L8/drafts/draft.docs.html

http://lists.oasis-open.org/archives/ubl-ndrsc/200111/msg00005.html

PDF-файл:

www.oasis-open.org/committees/download.php/6233/c002349_IS0_IEC_11179

Черновик:

www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c002349_IS0_IEC_11179-1_1999(E).zip

Стандарт ISO-11179 разбит на шесть разделов:
11179-1: Framework for the Specification and Standardization of Data Elements Definitions
11179-2: Classification for Data Elements
11179-3: Basic Attributes of Data Elements
11179-4: Rules and Guidelines for the Formulation of Data
11179-5: Naming and Identification Principles for Data
11179-6: Registration of Data Elements

ISO-11179 для SQL

Обоснование
Формальные стандарты хороши, но слишком общи. Удобно превратить их в набор правил, написанных на языке, понятном разработчику SQL Некоторые из данных здесь формулировок являются результатом консенсуса экспертов и взяты из групп новостей и частной переписки.
Согласно правилам стандарта ISO-11179-4 скалярный элемент данных должен удовлетворять следующим требованиям.
1. Он уникален (в пределах своего словаря данных).
2. Он назван с использованием единственного числа.
3. В имени поясняется, чем является элемент, а не чем он не является.
4. Имя читается, как описательная фраза.
5. Имя содержит только общепринятые сокращения.
6. Имя не содержит вложенных определений других элементов данных или понятий.
7. Таблицы, наборы и другие сборные элементы именуются обобщающими понятиями во множественном числе.
8. В имени процедуры содержится глагол.
9. В имя копии (псевдоним) таблицы включено имя базовой таблицы и причина создания копии.
В теории все это звучит прекрасно, но в реальном мире на имена накладываются дополнительные практические ограничения, например ограничение длины или допустимые символы. Другая проблема состоит в том, что у элемента данных в зависимости от контекста его использования могут быть разные имена. В отчете он назван так, в файле электронного обмена данными (electronic data interchange, EDI) по-другому, причем оба имени могут отличаться от имени в БД. Но в пределах одной БД использовать разные имена для одного элемента не стоит, да и в разных БД одного предприятия этим не стоит злоупотреблять. К сожалению, найти подобные разногласия без хорошего словаря очень трудно. Словарь данных должен включать внешние имена и их контекст.

Исключения
Над всеми нами довлеет проклятие старых БД, старых файловых систем и прочих традиций. Если у элемента имеется устоявшееся и понятное имя, его можно использовать даже вопреки стандарту. Например, для столбца с почтовым индексом формально правильным будет имя “us_postal_code”, но вместо него можно поставить более привычное “zip_code” или даже просто “zip”.

Уровни абстрагирования

Разработка имени начинается на концептуальном уровне. Класс объекта представляет идею, абстракцию или предмет реального мира, например дерево или страну. Свойство, например, высота или идентификатор, описывает все объекты класса. Это позволяет создавать словосочетания типа “высота дерева” или “идентификатор страны”, комбинируя класс и свойство.
Этот уровень — логический. Полное логическое имя элемента данных должно включать способ представления значений из его области определения (набора допустимых значений). Так мы получаем в качестве возможных элементов данных “меру высоты дерева”, “имя идентификатора страны” и “код идентификатора страны”.
Между именем идентификатора и кодом идентификатора имеется различие, правда, столь тонкое, что мы можем не захотеть его моделировать. В этом случае необходимо правило, в соответствии с которым название свойства исключается из имени элемента данных. При этом в структуре элемента свойство сохранится, лишь перестав быть частью его имени.
Некоторые логические элементы данных могут считаться общепринятыми, если они четко определены и применяются многими организациями. Например, названия и коды стран описаны в стандарте ISO-3166 “Codes for the Representation of Names of Countries”, который можно использовать в качестве справочника.
Заметьте, что, по правилам стандарта ISO-11179, это самый высокий уровень, на котором появляются истинные элементы данных: у них есть класс, свойство и способ представления.
Далее идет прикладной уровень. Он обычно реализуется при помощи неких конкретных уточнений, соответствующих поставленной задаче: выделения подмножества из области значений данных, добавления ограничений, гарантирующих, что мы будем иметь дело лишь с допустимыми значениями. Например, мы используем коды стран ISO-3166, но реально работаем только с европейскими государствами. Это означает, что нас интересует подмножество стандарта, которое временным изменениям практически не подвержено. С другой стороны, набор стран, в которых в текущем году выпало больше всего осадков, может на протяжении года меняться неоднократно.
Эти уточнения включаются в имя посредством добавления к логическому имени конкретного квалификатора. Например, если нужно составить список стран, с которыми у некой организации есть торговые соглашения, элемент данных запроса можно назвать “trading_partner_country_name” (название страны-торгового партнера), подчеркнув тем самым его роль. Область значений будет представлять собой подмножество стран из стандарта ISO-3166.
Ниже всего располагается физический уровень. На нем находятся имена, которые фигурируют в заголовках столбцов таблицы, описаниях файлов, разметке EDI-файлов и т.д. Эти имена могут быть, с одной стороны, сокращенными из-за различных ограничений на длину или набор символов, с другой стороны, могут содержать информацию о формате и источнике.
В реестре все имена элементов данных и компоненты имен всегда будут указываться в паре со своим контекстом, чтобы мы легко могли установить их источник и назначение. Цель заключается в возможности проследить за каждым элементом данных от его создания до любого применения, под каким бы именем он ни фигурировал.