Блог

Я столкнулся с интересной проблемой. Я унаследовал базу данных для процесса daemon, который опрашивает и принимает отчеты от удаленных встроенных систем. Каждый сайт, на котором установлена одна из этих систем, может отслеживать более десятка различных топливных баков. (На практике большинство отслеживают 2, 3 или 4 резервуара.)

Когда что-то происходит, например, происходит пополнение резервуара или резервуар достигает минимального уровня, программа сохраняет это событие в базе данных Postgres. Изначально база данных создавалась таким образом, что она сохраняла всю информацию из каждого топливного бака (тип топлива и т.д.) В записи события, хотя существовала отдельная таблица «баки». Я добавил поле внешнего ключа в таблицу, чтобы связать его с конкретным встроенным модулем, и внешний ключ в таблицу событий, чтобы связать его с конкретным резервуаром.

Теперь вот в чем проблема: резервуары могут быть добавлены, удалены или изменить тип топлива, которое они хранят, в любое время. Добавление резервуаров не должно быть проблемой, но если один из них будет удален, записанные события будут «осиротевшими». Хуже, если тип топлива изменен, скажем, с «реактивного» на «ракетный», тогда, когда кто-то просматривает историю, они подумают, что все эти старые события произошли с «ракетным» топливом, когда на самом деле они произошли с «реактивным» топливом.

Я получил пару предложений в автономном режиме: (1) создайте вторую архивную таблицу танков, и когда что-либо изменится, переместите эту запись о танках с ее уникальным идентификатором в архивную таблицу и создайте новую запись с новым идентификатором для нового состояния танка или (2) и полем «активный» в таблицу танков, и все равно создавайте новые строки при изменении спецификаций, но только помечайте текущее состояние танков как «активное».

Есть ли у кого-нибудь мнение об этих предлагаемых решениях или другая идея, которая может сработать?

Добавление резервуаров не должно быть проблемой, но если один из них будет удален, записанные события будут «осиротевшими». Хуже, если тип топлива изменен, скажем, с «реактивного» на «ракетный», тогда, когда кто-то просматривает историю, они подумают, что все эти старые события произошли с «ракетным» топливом, когда на самом деле они произошли с «реактивным» топливом.

Только потому, что кто-то добавил ограничение внешнего ключа без полного понимания исходного дизайна. Посмотрите, сможете ли вы найти этого человека и поговорить с ним строго. Много виляйте пальцем.

В чем проблема? Вся соответствующая информация содержится в записи события; или когда вы создавали связь между резервуаром и событием, вы не сохранили информацию о резервуаре? . Тот факт, что она потеряна, не является проблемой, поскольку удаление типа топлива из таблицы событий является причиной проблемы.

Существует несколько причин для сохранения пересылки информации. одним из которых является история. Связывая таблицы обратно с объектом tank, приятно, что он показывает вам текущее состояние. таблица событий показывает историю, если «тип» отличается от типа в таблице резервуаров..

Я думаю, я недостаточно хорошо понимаю проблему:

Хотят ли пользователи видеть все события, даже если резервуар удален?

Решит ли проблему добавление ассоциативной таблицы между резервуаром и событиями для типа резервуара с датами начала и окончания?

Что плохого в сохранении некоторой информации о резервуаре для события? Таким образом, вы узнаете состояние хранилища на момент возникновения события?