Отправляет email-рассылки с помощью сервиса Sendsay

Программирование и готовые решения

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 5.410 RSS
←   Апрель 2008   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


За последние 60 дней ни разу не выходила


Сайт рассылки: http://blog.leadersoft.ru
Открыта: 29-08-2000

Автор
leadersoft.ru

Статистика

5.410 подписчиков
0 за неделю
←   Все выпуски   →

Microsoft Access - программирование и готовые решения


Выпуск 89. Материалы для начинающих (36 урок)

Подписка: "Access 2000 - программирование и готовые решения"
Дата: 08 04.2008
Автор: Парусников Алексей (aka Palarm)
Сайт: http://www.accessoft.ru под редакцией с http://www.leadersoft.ru/
Новые материалы: Вопросы при проектировании БД
На сайте AccesSoft публикуются статьи, посвященные вопросам, связанным с разработкой приложений Access. Вопросы по работе с Access Вы можете задать на форуме. Вы так же можете ознакомиться с готовыми программами, получить исходный код, купить программу, связаться с автором для решения вопроса о доработке программы под Ваши требования.

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

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

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 не позволяет группировать объекты в дерево. Хотя это давно уже надо было бы сделать разработчикам.

Ссылки на программы
http://shops.leadersoft.ru/Catalog.aspx?MarketID=1  - все базам данных Access, SQL Server
http://shops.leadersoft.ru/Catalog.aspx?MarketID=18 - все коммерческие программы

Ссылки для фрилансеров (freelanser)
http://shops.leadersoft.ru/Catalog.aspx?TypeID=1 - RSS новости для фрилансеров и программистов
http://shops.leadersoft.ru/Catalog.aspx?MarketID=42 - избранное для фрилансеров

Для начинающих фрилансеров, кто думает работать и "за границей"  рекомендую изучить эту ссылку http://shops.leadersoft.ru/Catalog.aspx?TypeID=1&MarketID=42&RssID=7&RssPath=0 Информация дана на английском языке. Тренировку мыслить по иностранному надо начинать с перевода абзаца по работе. Там дано всего 3-5 строк текста. Эту работу можно поручить и авто-переводчику. Проблема в  том, что из текста нужно составить правильное предложение на русском так, так чтобы было понятно вам и другим. Если получиться, то возможна оплата 5 рублей за каждый такой абзац.

Примеры перевода.
Конвертор отчетов Crystal Reports 
Добрый день. Я в настоящее время использую сервер отчетов с Crystal Reports XI Server. Но сам процесс обработки данных идет слишком медленно, мне нужен специалист, кто смог бы мне решить эту проблему. Бюджет $300-$1000, Знания: JSP, Programming 08.04.2008

Портал по работе 
Уважаемые специалисты, мне нужен портал по работе, который будет клоном сайта http://www.bdjobs.com/. Функционально он должен быть уникальным. Этот проект должен быть разработан и создан с использованием Joomla 1.5 ... (Бюджет $1000 - $3000)

 
В избранное