|
Есть множество «чайных» учебников, где подробно разжевывается, как с помощью мастеров создавать таблицы, формы, отчеты (хотя мастера как раз и не пользуются «построителями») – но опускаются или вскольз упоминаются некоторые важные моменты, невнимание к которым может создать серьезные проблемы, вплоть до кардинальной переработки всего проекта и переносом данных («распиливания», «сборки» таблиц, редактирования модулей, форм, отчетов и т. д.). Рассмотрим некоторые из них.
1. Соглашения об именах полей, элементов управления и объектов
1.1. Пробелы в именах
Вот общие правила (согласно Help), которых следует придерживаться:
- имя должно содержать не более 64 знаков;
- имя может включать любую комбинацию букв, цифр, пробелов и специальных знаков за исключением точки (.), восклицательного знака (!), надстрочного знака (`) и квадратных скобок ([ ])
- не должно начинаться с знака пробела
- не должно включать управляющие знаки (с кодами ASCII от 0 до 31)
- не должно включать прямые кавычки (") в именах таблиц, представлений и сохраненных процедур в проекте Microsoft Access.
Дело в том, что если с именами предполагается работать с помощью процедур VBA, то в некоторых случаях будет довольно проблематично обращаться к имени объекта, если оно содержит пробелы. Например, при обращении к имени с пробелом, его нужно заключать в квадратные скобки, что не совсем удобно. Но в некоторых выражениях скобки не допустимы. В результате придется переименовывать объект, что часто влечет за собой большие проблемы с работой программы, или искать «обходные пути». Поэтому, лучше выбрать один из вариантов:
ИмяОбъекта
Имя_Объекта
1.2. Кириллица или латиница?
Еще один часто обсуждаемый вопрос: национальная символика в именах объектов. Основная проблема, с которой можно столкнуться при ее использовании:
программа, в ко��орой для названия объектов используются национальные символы, НЕ БУДЕТ РАБОТАТЬ в системе, в которой нет поддержки этого языка.
Особенно это касается кириллицы (русский алфавит). Именно по этой причине разработчики, которым приходится работать на разных версиях офиса (и тем более за границей) настаивают на использовании английских имен. Однако, иногда одной лишь замены символов бывает не достаточно – чтобы приложение 100% работало в английской версии, оно должно быть создано в АНГЛИЙСКОЙ ВЕРСИИ офиса. Кроме того, использование кириллицы создает проблемы:
- при использование сторонних утилит – они могут не работать с русскими названиями объектов. Но даже и «со своими» функциями может быть проблема. Попробуйте, к примеру, создать функцию в модуле формы, и вызвать ее, прописав в свойствах формы на какое либо ее событие =Моя_Функция(). Access ее «не увидит». Хотя, если обратиться к той же функции в коде модуля – все работает. Это говорит о том, что полной русификации нет.
- постоянное переключение раскладки клавиатуры. У многих это вызывает раздражение.
- если вы планируете работать за рубежом (или с английскими версиями программ), то имеет смысл приучать себя к общепринятому стандартному обозначению имен объектов.
Прочитав вышесказанное, создается впечатление, что на вопрос, как называть объекты БД, ответ очевиден, однако не все так просто. Для начала глянем на соседей.
Кто работал за границей, тот знает, что немцы практически всегда называют объекты по-немецки, а французы по французски и т. д., да и вообще европейцы в этом смысле не дисциплинированны (как, впрочем, и все остальные). Стало быть, если им можно, почему нам нельзя? Хотя им конечно проще – у них латинский алфавит. Ну а если серьезно, то использование национальных названий имеет и свои преимущества:
- меньше шансов назвать что-нибудь так, что потом вызовет смех у носителя языка (да и любого, более менее владеющего английским)
- гораздо быстрее визуально ищется запрос или таблица среди сотен им подобных, гораздо быстрее понимается смысл забытых выражений, запросов и т. д.
Хотя такие аргументы покажутся «не серьезными» сторонникам «английской школы» (привыкнется, заодно и английский подучишь), но, тем не менее, иногда этого достаточно, чтобы перейти к национальным обозначениям, особенно, если не планируется использовать программу на других языковых версиях офиса.
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Итог_продаж и т. д.
Хотя такой подход многие называют «дурным тоном», тем не менее, он довольно часто имеет место. Видимо дело все в том же: так легче визуально искать объект, а английский префикс выделяется среди русских букв, облегчая понимание. И даже переключение раскладки клавиатуры не останавливает.
Вывод:
В конечном итоге, как называть объекты базы данных – это личное дело разработчика, и во многом зависит от того, ЧТО он пишет, ДЛЯ КОГО и ЗАЧЕМ. При этом помните о возможных проблемах, если используете кириллицу. Но, главное:
Используйте для обозначения объектов БД осмысленные имена в соответствии с соглашением об именах объектов. При этом, крайне желательно придерживаться какой либо системы обозначений – это значительно облегчит понимание структуры базы.
|
Дополнение от www.leadersoft.ru .
Если Вы делаете проект adp проект. Он применяется, когда Вы разрабатывает базу данных на Access+SQL Server, то желательно все объекты называть и по имени проекта. Например, market_, student_, dnn_ и т.п. это позволит Вам избежать конфликта объектов. Например, Вы используете CRM систему сайта Dotnetnuke, то в ней может быть несколько десятков, а то и сотен объектов (зависит от установленных модулей). В таком количестве объектов очень легко потеряться. Префикс проекта, позволит Вам быстро найти нужный объект: таблицу, запрос, процедуру и т.п. Пример. Таблица: Market_Products, процедуры: Market_UpdateProduct, Market_DeleteProduct, Market_InsertProduct. Объекты CRM системы желательно начитать с dnn_forum_ .. P.S. К сожалению интерфейс Access и менеджер баз данных SQL Server не позволяет группировать объекты в дерево. Хотя это давно уже надо было бы сделать разработчикам.
Примеры перевода.
Конвертор отчетов Crystal Reports
Добрый день. Я в настоящее время использую сервер отчетов с Crystal Reports XI Server. Но сам процесс обработки данных идет слишком медленно, мне нужен специалист, кто смог бы мне решить эту проблему. Бюджет $300-$1000, Знания: JSP, Programming
Портал по работе
Уважаемые специалисты, мне нужен портал по работе, который будет клоном сайта http://www.bdjobs.com/. Функционально он должен быть уникальным. Этот проект должен быть разработан и создан с использованием Joomla 1.5 ... (Бюджет $1000 - $3000)
|