Это в значительной степени основано на Как контролировать версию записи в базе данных и http://www.sqlitetutorial.net/sqlite-trigger/:
Вам нужно будет найти свои бизнес-правила о том, что для версии ичто обновлять когда.Например, если клиент меняет свой адрес, какие заказы вы хотите обновить / изменить.Конечно, вы не хотите обновлять заказы с новым адресом, когда эти заказы были выполнены и оплачены уже год назад.Но вы, безусловно, хотите обновить адрес в заказах, которые еще не были отправлены.Но для заказов, которые были отправлены, но еще не поступили, изменение адреса доставки создаст путаницу для всех вовлеченных сторон.
Кроме того, для целей аудита вы можете отслеживать все изменения в определенных полях данных,Но по другим нормативным причинам, таким как GDPR, может потребоваться установить дату окончания срока действия таких изменений.
Итак, прежде чем принять решение о том, какую схему управления версиями использовать, подумайте, как управление версиями будет использоваться позже в запросах.
Подход, который легче всего привязать к существующей схеме, заключается в том, чтобы иметь для каждой таблицы mytable вторую таблицу mytable_log, которая заполняется через триггеры базы данных и сохраняет старую строку, новую строку и(база данных) пользователя и действия.Таким образом, все, что ваше приложение делает с базой данных, автоматически записывается в журнал без особого влияния на существующие запросы.Вам нужно будет найти способ сообщить действующему пользователю о базе данных, либо через вход в базу данных, либо через дополнительную переменную или хранимую процедуру.
Другой подход заключается в том, чтобы покончить с консолидированной / текущей таблицей ихранить историю и текущее состояние в одной таблице и иметь представления, отражающие текущее состояние мира.Это означает, что вы можете полностью отказаться от триггеров базы данных, а также отменить все разрешения на удаление / обновление таблиц для пользователей.Недостатком является то, что ваша программная логика выберет самую новую версию каждого клиента (или чего-либо еще), что можно сделать с помощью оконных функций, но это будет медленнее, чем при наличии сводной таблицы.Кроме того, в этом случае вам необходимо соблюдать осторожность при фактическом удалении строки из базы данных (скажем, по причинам GDPR).Даже если строке более 10 лет, она все еще может быть текущей, потому что нет более новой версии доступной строки.