Строке нужен устойчивый смысл
Сначала определите, что представляет одна запись: заявку, выполненную операцию или отдельное изменение состояния. Если эти сущности смешать, итоговая таблица станет неоднозначной. Например, планируемое обслуживание не должно выглядеть как уже выполненное только потому, что у него указана дата. Записи нужен устойчивый идентификатор. Название оборудования или номер видимой строки не всегда подходят: текст могут изменить, а сортировка переставляет элементы. Также различают время события и время внесения сведений. Работа могла быть выполнена вчера, а описание добавлено сегодня. Оба значения полезны, если ясно, какой вопрос каждое из них закрывает.
Исправление не должно незаметно заменять прошлое
Представим, что сначала в журнал внесли замену детали, а затем уточнили её обозначение. Если сохранить только новую строку, будет трудно понять, что изменилось и почему. История правок может фиксировать автора действия, время, тип изменения и необходимые сведения о прежнем и новом состоянии. Но журнал изменений не должен бесконтрольно копировать всё содержимое системы. Пароли, ключи доступа и лишние чувствительные сведения не нужны для большинства задач проверки. Состав истории определяют по цели и правилам доступа. Также учитывают надёжность самой записи события: наличие строки в логе ещё не делает её независимым доказательством, если любой пользователь может переписать этот лог.
Права и одновременная работа входят в модель
Один пользователь может читать записи, другой создавать, третий подтверждать выполненную операцию. Возможность нажать кнопку не должна быть единственным контролем: сервер проверяет, разрешено ли действие конкретному участнику и для выбранной записи. Проверка относится и к просмотру, и к изменению данных. Отдельный случай возникает, когда два человека открыли одну версию. Первый исправил описание, а второй позже сохранил старую форму, случайно затерев правку. Система должна иметь определённое правило обнаружения и разрешения такого конфликта. Например, можно сравнивать версию записи и просить пересмотреть изменения. Резервная копия решает другую задачу: восстановление после потери данных. Она не заменяет понятную историю действий и проверку полномочий.
Попробуйте на практике
Спроектируйте бумажную модель электронного журнала для вымышленного обслуживания трёх приборов, не используя реальные персональные данные.
- Определите смысл одной строки и перечислите поля: идентификатор, прибор, событие, его время, время внесения и состояние. Разделите запланированное и выполненное.
- Создайте учебную запись, затем исправьте обозначение детали. Покажите, какая информация должна остаться в истории изменения и зачем.
- Назначьте три условные роли: читатель, автор и подтверждающий. Для каждой укажите допустимые действия без автоматического предоставления полного доступа.
- Смоделируйте одновременную правку двумя авторами. Запишите, как система обнаружит устаревшую версию и не затрёт новое содержимое молча.
Как проверить результат. У записи есть устойчивый идентификатор, два вида времени не смешаны, исправление прослеживается, а конфликт сохранения имеет явное правило. История не содержит ненужных секретов и не подменяет резервное копирование.
Частые вопросы
Достаточно ли хранить дату последнего изменения?
Она показывает только последнее время правки. Для восстановления последовательности могут понадобиться сведения об отдельных действиях, их авторах и причинах. Набор данных выбирают по задаче.
Любое удаление нужно запрещать навсегда?
Нет. Политика зависит от назначения системы и применимых требований. Важно заранее определить, кто вправе удалять, что означает удаление для истории и как выполняется восстановление, если оно предусмотрено.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.