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

1. Понятное ТЗ.
Техническое задание, которое ставит вас в тупик убъет вашу базу, сколь хорошим программистом вы бы не были. Всегда следует помнить, что ваш взгляд на проблему - это ваш взгляд. Навязать его будущему пользователю можно, но от этого он работать лучше и быстрее не станет.
И это касается не только интерфейса. Хотя это и есть то, к чему у пользователя чаще всего возникают претензии. Но, нередко пользователь говорит: а можно здесь сделать так, а тут так. И начинаешь понимать, что нарисованная схема данных летит к черту, потому что вы неправильно поняли ТЗ, или ТЗ было сформировано нечетко.
ПРОПИСЫВАЙТЕ ТЗ на бумаге вместе с пользователем, вплоть до каждого поля и каждой связи. Рисуйте формы, уточняйте тонкости будущего интерфейса. Чем точнее будет рисунок, тем проще будет работать вам. До 50% времени тратится на сидение возле монитора и мыслей "чтобы еще такого сделать" - от этого не уйти (если вы, конечно, программист и в душе), но затраты времени можно сократить до 5-10%.
Второй вариант: писать программы на основе уже работающей (существующей) программы но с меньшим функционалом или просто убогой в силу разных причин. НЕ КОПИРОВАТЬ, а использовать уже работающую схему, как указание для действий.

2. Если ТЗ вам понятно, то можно приступать к созданию схемы данных. ИСПОЛЬЗУЙТЕ реляции. Если вы их не используете, значит, Access со своим функционалом не так уж и нужен. Основной плюс MS Access именно в наличии реляций. Реализация каскадного обновления и в первую очередь каскадного удаления позволяет не думать о зачистке базы данных и куче мусора в данных. Во-вторых, это дает существенную экономию места под данные. Как я уже упоминал в ряде статей, годичная база с 10 таблицами в сумме на 100-200 тыс. записей из 10-30 полей занимает у меня 10-20 Мб.

3. НЕ ЗЛОУПОТРЕБЛЯЙТЕ реляциями, если вы рассчитываете, что число записей в таблицах будет превышать 2-5 тыс. Два примера.
- Запрос хватает информацию о названии товара из справочника по коду в своем поле. Если кол-во товаров будет превышать некую критическую величину, то через какое-то время открытие запроса станет большим. Удаление же строки из справочника приведет к неправильной ссылке в запросе.
- Запрос стоимости заказа = сумма стоимости отдельных позиций. Получать такой результат в запросе можно через DSum или свою функцию. Гораздо быстрее работает вложенный запрос типа "SELECT SUM(sm) AS sm FROM tbl", но и он через какое-то время начнет заикаться.
Резюме: сохраняйте расчетную информацию в темповых полях, если вы планируете работу базы с большим числом записей.

4. Должна ли база быть сетевой? Т.е. должны таблицы храниться в клиенте или быть прилинкованными. Для меня такого вопроса давно нет: все данные должны быть прилинкованными. Локальными остаются: темповая таблица, таблицы-хранители локальной информации (пути к базе данных, таблица-список прилинкованных таблиц, таблица-список отчетов), т.е. информация, которая напрямую зависит от версии клиента.
Что это дает? Вы легко и быстро меняете клиента (без импорта/экспорта данных). База уже готова как сетевой вариант.

5. Когда защищать базу данных? Если планируете закрывать данные и код с помощью файла групп, то лучше делать это сразу и только с помощью мастера MS Access. Последнее позволит избежать множества косяков.
Сделать защиту на работающей базе данных, это остановить работу на сутки и сделать базу возможно неработоспособной (забудете дать права на какой-нибудь запрос, например). Пример: уже полгода собираюсь закрыть таким образом одну из разработок, но не могу в силу разных причин (не возможности остановить конвейерную работу, придется неделю стоять рядом и исправлять возможные косяки, да и просто руки дрожжат).

6. Интерфейс - это важно, но если нет приличной схемы данных, то как его не строй.) Вопрос интерфейса - это отдельный вопрос, и его мы обсудим в другой статье.

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

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам