Как реализовать историю API?

Question

[xiiicool]

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

Comments

[Дмитрий]

Правильное решение можно выбрать только на месте. Но как вариант сделать одну таблицу а историческую запись хранить как json

[Сергей Соколов]

Историю как предполагается использовать —
откатывать изменения пошагово назад, или просто для аудита, посмотреть что там было?

[xiiicool]

Сергей Соколов, скорее всего для аудита

[Александр Лыкасов]

Обычно логируют события происходящие в приложении и некий контекст события. Обычно это всё можно в одной таблице хранить.

[Константин Цветков]

Какая конкретно используется СУБД? В некоторых есть различные встроенные средства журналирования.

[xiiicool]

Константин Цветков, mysql

[mayton2019]

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

[pfg21]

Максим, логирование действий с базой данных к примеру.
https://dev.mysql.com/doc/refman/8.0/en/binary-log.html
или сделать логирование операций на уровне программы.

Answer 1

[Станислав Макаров]

Включив телепатию, предположу, что правильное решение для вашего случая - хронологическая база данных и стандарт SQL:2011 (ну или что-то аналогичное в вашей СУБД - не все вендоры стремятся реализовать этот стандарт буква в букву).

Конкретнее можно будет поговорить, если объясните, что вы понимаете под "историей" и какая у вас СУБД.

Ещё: 1, 2, 3, 4.