Архивирование базы данных с полной базой данных

Имею реляционную базу данных MySQL. Требование состоит в том, чтобы заархивировать записи нескольких таблиц и связанные с ними записи, чтобы полностью удалить их из активной базы данных и заархивировать их для последующего доступа, если это необходимо. Веб-приложение построено на Rails BTW.

Есть ли способ, при котором любая вставка или обновление исходной базы данных отражается в архивной базе данных, а удаления в исходной базе данных не обновляются в архивной базе данных.

Таким образом, в архивной базе данных есть полные данные, как активные, так и заархивированные. А исходная база данных содержит только данные, доступные в режиме реального времени.

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

С фреймворком Rails удаление связанных и зависимых записей относительно просто, если зависимый: :destroy настроен правильно.


person kishore    schedule 11.06.2020    source источник
comment
Я не уверен, какова точная цель этого может быть. Это явно не резервная копия, потому что живую теневую базу данных можно взломать так же, как и исходную. Я почти уверен, что есть более элегантные способы достижения цели (мне это кажется проблемой XY).   -  person B from C    schedule 11.06.2020


Ответы (1)


Есть ли способ, при котором любая вставка или обновление исходной базы данных отражается в архивной базе данных, а удаления в исходной базе данных не обновляются в архивной базе данных.

Контрпример "Я"

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


Если заархивированная база данных также обладает всеми техническими свойствами исходной, это контрпример "II":

Представьте себе таблицу, в которой для некоторых столбцов определены группы UNIQUE: UNIQUE (имя, фамилия, место рождения, дата рождения)

Теперь кто-то удаляет Джейн Доу, Лондон, 01 января 2000 г. Однако теневая таблица сохранит эту запись.

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

person B from C    schedule 11.06.2020