...

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

1. Соглашения об именах полей, элементов управления и объектов

1.1. Пробелы в именах

Вот общие правила (согласно Help), которых следует придерживаться:

  • имя должно содержать не более 64 знаков;
  • имя может включать любую комбинацию букв, цифр, пробелов и специальных знаков за исключением точки (.), восклицательного знака (!), надстрочного знака (`) и квадратных скобок ([ ])
  • не должно начинаться с знака пробела
  • не должно включать управляющие знаки (с кодами ASCII от 0 до 31)
  • не должно включать прямые кавычки (") в именах таблиц, представлений и сохраненных процедур в проекте Microsoft Access.

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

ИмяОбъекта
Имя_Объекта

1.2. Кириллица или латиница?

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

программа, в которой для названия объектов используются национальные символы, НЕ БУДЕТ РАБОТАТЬ в системе, в которой нет поддержки этого языка.

Особенно это касается кириллицы (русский алфавит). Именно по этой причине разработчики, которым приходится работать на разных версиях офиса (и тем более за границей) настаивают на использовании английских имен. Однако, иногда одной лишь замены символов бывает не достаточно – чтобы приложение 100% работало в английской версии, оно должно быть создано в АНГЛИЙСКОЙ ВЕРСИИ офиса. Кроме того, использование кириллицы создает проблемы:

  • при использование сторонних утилит – они могут не работать с русскими названиями объектов. Но даже и «со своими» функциями может быть проблема. Попробуйте, к примеру, создать функцию в модуле формы, и вызвать ее, прописав в свойствах формы на какое либо ее  событие =Моя_Функция(). Access ее «не увидит». Хотя, если обратиться к той же функции в коде модуля – все работает. Это говорит о том, что полной русификации нет.
  • далеко не все команды VBA поддерживают обращение к объектам на кириллице.
  • постоянное переключение раскладки клавиатуры. У многих это вызывает раздражение.
  • если вы планируете работать за рубежом (или с английскими версиями программ), то имеет смысл приучать себя к общепринятому стандартному обозначению имен объектов.

Прочитав вышесказанное, создается впечатление, что на вопрос, как называть объекты БД, ответ очевиден, однако не все так просто. Для начала глянем на соседей.

Кто работал за границей, тот знает, что немцы практически всегда называют объекты по-немецки, а французы по французски и т. д., да и вообще европейцы в этом смысле не дисциплинированны (как, впрочем, и все остальные). Стало быть, если им можно, почему нам нельзя? Хотя им конечно проще – у них латинский алфавит. Ну а если серьезно, то использование национальных названий имеет и свои преимущества:

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

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

1.3. Собственная система обозначений

Разобравшись с алфавитом, перейдем теперь к именам. Вот основные правила, на которых сходятся все разработчики:

  • называйте объекты БД, используя осмысленные имена и префиксы, по которым можно будет определить, к какой группе относится объект. В окне проекта они отсортируются по алфавиту, что значительно облегчит понимание (и вспоминание через какое то время) структуры базы данных
  • старайтесь придерживаться однообразной системы обозначений (если ее нет - придумайте). Так вы значительно облегчите себе (и другому, кто будет разбираться в ваших творениях потом) разбор структуры базы

Вот пример системы, используемой «ПрограммистЛюбитель» (часто появляется на SQL.ru)

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

Для запросов префиксы:

qr - обычный запрос делающий SELECT из одной/нескольких таблиц
sel - фильтрующий только уникальный записи по части полей
sum - суммирующий/агрегатирующий данные
pvt - перекрестный/сводный запрос
ins - на вставку данных
upd - на обновление данных

Для полей таблиц:

<префикс> + <корень таблицы> + <доп. слово-описание, иногда два>
i<Корень - имя таблицы>ID - счетчик, почти всегда PrimaryKey
i<Корень>Code - уникальные коды не счетчик, часто PrimaryKey
s<Корень>Code - уникальные буквенные коды
i<Корень>Nomer - номера по порядку
s<Корень>Name, s<Корень>Description, s<Корень>Comment - думаю, ясно
n<Корень>Count - количестко чего-либо
dt<Корень>Birthday, dt<Корень>From, dt<Корень>To и т.п. – даты

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

Имена объектов – префиксы объектов на английском, имена на русском
Имена модулей, функций, процедур – на английском
Имена полей таблиц – префиксы на английском, имя поля на русском

В результате получается:

Имена полей таблицы типа: id, idПоставщик, sПримечание и т. д.
Имена запросов: qryRptСводка_сдачи, qrySumИтог_продаж и т. д.

Хотя такой подход многие называют «дурным тоном», тем не менее, он довольно часто имеет место. Видимо дело все в том же: так легче визуально искать объект, а английский префикс выделяется среди русских букв, облегчая понимание. И даже переключение раскладки клавиатуры не останавливает.

Вывод:

В конечном итоге, как называть объекты базы данных – это личное дело разработчика, и во многом зависит от того, ЧТО он пишет, ДЛЯ КОГО и ЗАЧЕМ. При этом помните о возможных проблемах, если используете кириллицу. Но, главное:

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


Комментарий к статье

Венгерская нотация - великая вещь. Она позволяет избежать возникновения в программе имён типа n, nn, nnn, n2 и т.п., которые ничего не значат. Немного потренировавшись, любой человек без труда начинает генерировать имена вроде idCustomer (первичный ключ покупателя), szCustomer (символьное обозначение покупателя -- имя), cntCustomer (счётчик покупателей), причём времени для изобретения таких слов требуется не больше, чем для nnn или n2.

Однако, в последнее время мне всё больше нравится модификация венгерской нотации, которую использует Microsoft в .NET Framework. Они теперь совсем не пишут префиксы типа в очевидных случаях, а там, где случай не совсем очевиден, префикс превращается в постфикс. Например, CustomerID (тип "ID" не в начале, а в конце), CustomerName (вообще не требует указания типа), CustomerCount (и так ясно, что целое), CustomerSelectionForm (форма для выбора покупателя -- содержит тип (Form) в конце, а не в начале).

У такого подхода есть несколько преимуществ.

  • СustomerSelectionForm выглядит более грамотно с точки зрения языка, чем frmCustSel
  • в среде разработки, когда IDE подсказывает окончания слов, лучше иметь список, в котором подряд по алфавиту перечислены все переменные, начинающиеся на "Cust...", нежели все переменные, начинающиеся на "id..."
  • взглянув на список "Cust...", мы сразу увидим все свойства, методы, поля и всё остальное, что относится к покупателю, а вот взглянув на список "id...", мы увидим имена нескольких десятков первичных ключей, что обычно совсем не интересно.

Но это, конечно же, дело вкуса. Главное, чтобы была система. Система есть - отлично, нет - код выглядит непрофессионально. Чем отличается профессионал от любителя? Тем, что его "рука мастера" видна в изделии. Так что любые "почерки" в коде приветствуются, а отсутствие "почерка" выдаёт либо недостаток опыта, либо простую небрежность.

Что касается русских букв, а ещё более того - пробелов, - я их избегаю всеми возможными способами. Для имени таблицы с клиентами я всем советую использовать tCustomer, не знаете английского - пусть будет tKlient. Но только не «Клиент магазина»! Единственное исключение - когда таблица поставляется кем-то со стороны в текстовом файле "постоянные покупатели.txt". Тогда я её гружу в таблицу t_постоянные_покупатели_txt, а то он потом мне пришлёт исправленный файл, а я уже забуду, куда его загружать. Но пробелы в любом случае - долой!

Павел Воронков

1 2 3 4 5 6 >>

Автор: sprt16@accessoft.ru