Которых можно было бы избежать.
Эта статья имеет некоторые пересечения с материалом "Проектирование базы данных", так что сначала отсылаю вас к нему.
1. Много будет строк или мало в таблицах, из которых берутся данные для расчетов. Простой пример: итоговая сумма заказа есть результат сложения сумм по каждому товару, та же в свою очередь является результатом вычисления - сумма*(1-скидка/100). Получаем несложную формулу для расчета итоговой суммы: SUM(сумма*(1-скидка/100))*(1-скидка_на_заказ/100)*(1+НДС/100).
В отчетах можно каждый раз пересчитывать итог, это даст динамику вашей базе, пользователь всегда будет видеть реальное состояние вещей. Но! Всегда это НО. Но с ростом базы, с увеличением количества строк вычисления будут делаться все медленнее. Так что, если вы видите, что количество строк за срок эксплуатации базы превысит примерно 5-10 тыс. в год, то стоит задуматься о статичных полях, которые будут на порядок быстрее работать в отчетах.
На практике это выглядит так. Обычно я делаю для заказов новый критерий: Состояние со значениями - "В работе", "Блокирован". При выборе "В работе" расчет итога идет динамически и нигде не запоминается. При выборе "Блокирован" итог расчитывается на текущий момент и записывается в статичное поле. В дальнейшем он не перерасчитывается. Единственное исключение: вернуть заказ в состояние "В работе" и снова заблокировать. В отчетах участвуют только блокированные заказы, рабочих заказов немного и все они в течение двух-трех суток становятся блокированными.
2. Невозможность редактировать базу. Нередко возникает необходимость в правке структуры рабочей базы данных, например, при очередном обновлении. Но если база уже рабочая, и с ней одновременно работают пять-десять клиентов, раскиданных по всему зданию, то редактирование структуры выливается в
- остановку рабочего процесса,
- нервы и время: обзвонить всех, чтобы вышли из программы, потом, чтобы обратно вошли.
Чтобы избежать этого, иногда полезно иметь несколько полей, не задействованных в процессе. На случай необходимой "горячей" доработки базы данных.
3. Синхронизация копий баз данных. Когда база уже в работе, то при очередном обновлении необходимо ее довести до полного совпадения в структуре с той копией, с которой вы работаете, как программист. Методов здесь много, но я предпочитаю записывать на бумажке поля, которые необходимо добавить в рабочую базу, а также таблицы, которые нужно импортировать.
Технически не так уж сложно сделать Апдейтер, который будет сам синхронизировать две копии базы. Так что если кто сподобится - буду рад посмотреть.
4. Имена таблиц и полей. Ну это избитая тема. Пока таблиц мало, то все понятно и легко, но стоит их числу перевалить за пятьдесят, все становится настолько запутанным...
У меня к понятным названиям отношение двойственное - я предпочитаю пользоваться собственной системой для названия запросов и таблиц. Поскольку никому другому она непонятна, то это дополнительная мера защита, как кода клиента, так и самой базы данных.
С другой стороны, если вести совсем деструктуризованную систему имен, то в итоге база будет переполнена непонятными запросами и таблицами - вроде и есть, но зачем они нужны, никто не знает.
5. Резервирование данных. Если база не резервируется, считайте ее одноразовой - после повреждения данных возможен вариант, когда никакие варианты восстановления не помогут. Здесь лучше перестраховаться.
Вот простая и надежная схема:
- резервирование-детектор. Резервирование данных в папку с согласия пользователя. Т.е. при открытии базы данных задается вопрос "Резервировать?". Если да, то данные сохраняются в отдельную папку на диске. Новые данные записываются поверх старой копии. Метод не слишком надежен, поскольку при сбое умная секретарша обязательно еще раз зарезервирует базу, прибив при этом старую и правильную копию новой, но поврежденной. Зато встревоженная, она обязательно позвонит вам и доложит о том, что база НЕ РЕЗЕРВИРУЕТСЯ! Это и будет звоночек об ошибке.
- резервирование недельное в скрытом режиме. Делаете папочку, до которой не так легко добраться и при каждом запуске клиента, если он видит базу данных локально (сетевым клиентам этого не надо доверять) даете ему копировать туда свеженькую копию. Секрет здесь в том, что для каждой копии меняется название. Если диск позволяет, то можно называть копию ДАТА_СЕГОДНЯ_НАЗВАНИЕ_БАЗЫ.mdb, если размер диска ограничен, то можно называть ДЕНЬ_НАЗВАНИЕ_БАЗЫ.mdb. Т.е. для понедельника копия называется, например, monday_base.mdb. Таким образом, если вы не будете идти к своему клиенту дольше недели, то у вас останется хотя бы одна работоспособная копия данных. Говорить клиенту о том, что такое вообще делается - нельзя. Во-первых, это нарушает его права о секретности информации (фактически делается куча несанкционированных копий), во-вторых, он не преминет при очередном сбое залезть туда и попытаться исправить все самому (зачем платить вам) - дело тут не в деньгах, когда клиент убил все резервные копии и радостно сообщил мне об этом по телефону, я чуть не поседел. Данных - за два года! Хорошо, откопал в мусорке на одном из трех компьютеров не самую поврежденную версию, и то потеряли 52 заказа, в каждом из которых по 2-10 изделий и 1-3 проведенных оплаты, 1-2 назначения на монтаж и многое другое...
6. Связи. Помните - вовремя не поставленная связь один-ко-многим с каскадным удалением обязательно приведет к появлению лишней информации и ошибкам в расчетах. Лучше сделать сразу, чем потом провести день, спрашивая можно ли удалить ту или иную запись, потому что она не вписывается в схему один-ко-многим. Не говоря уж о неизвестных данных второго уровня, например, изделия в заказах, которые без заказа вообще бессмыслены. Если заказ удален, то автоматически должны удаляться его составляющие. |
