История изменений

Наверняка он уже существует

Да, много где видел с разными вариациями:

• Актуальные данные хранятся в самой таблице, а старые версии в таблице *_history. Плюсы данной схемы: а) не надо делать join, чтобы получить актуальные данные; б) можно упростить запись новых данных с помощью триггеров: ты просто делаешь update в таблицу customer, как если бы таблицы customer_history не существовало, а запись в таблицу customer_history выполняет триггер автомагически.
• Актуальные данные хранятся в самой таблице, а старые версии в той же таблице в отдельном JSON-поле. Плюсы те же самые, как и в прошлом варианте, только ещё проще становится получать предыдущие версии.
• Актуальные данные хранятся в самой таблице, а старые версии для всех версионируемых таблиц хранятся в одной таблице versions (table_name text, data jsonb, inserted_at timestamp). Плюс — не нужно создавать новую таблицу *_history для каждой таблицы, у которой ты хочешь отслеживать версии. Явный минус — нельзя навесить внешние ключи.

У каждого варианта есть свои минусы, серьёзность которых будет зависеть от используемой СУБД и типовых запросов, которые ты в своём приложении будешь выполнять с этими данными.

Наверняка он уже существует

Да, много где видел с разными вариациями:

• Актуальные данные хранятся в самой таблице, а старые версии в таблице *_history. Плюсы данной схемы: а) не надо делать join, чтобы получить актуальные данные; б) можно упростить запись новых данных с помощью триггеров: ты просто делаешь update в таблицу customer, как если бы таблицы customer_history не существовало, а запись в таблицу customer_history выполняет триггер автомагически.
• Актуальные данные хранятся в самой таблице, а старые версии в той же таблице в отдельном JSON-поле. Плюсы те же самые, как и в прошлом варианте, только ещё проще становится получать предыдущие версии.
• Актуальные данные хранятся в самой таблице, а старые версии для всех таблиц хранятся в одной таблице versions (table_name text, data jsonb, inserted_at timestamp). Плюс — не нужно создавать новую таблицу *_history для каждой таблицы, у которой ты хочешь отслеживать версии. Явный минус — нельзя навесить внешние ключи.

У каждого варианта есть свои минусы, серьёзность которых будет зависеть от используемой СУБД и типовых запросов, которые ты в своём приложении будешь выполнять с этими данными.

Наверняка он уже существует

Да, много где видел с разными вариациями:

• Актуальные данные хранятся в самой таблице, а старые версии в таблице *_history. Плюсы данной схемы: а) не надо делать join, чтобы получить актуальные данные; б) можно упростить запись новых данных с помощью триггеров: ты просто делаешь update в таблицу customer, как если бы таблицы customer_history не существовало, а запись в таблицу customer_history выполняет триггер автомагически.
• Актуальные данные хранятся в самой таблице, а старые версии в той же таблице в отдельном JSON-поле. Плюсы те же самые, как и в прошлом варианте, только ещё проще становится получать предыдущие версии.
• Актуальные данные хранятся в самой таблице, а старые версии для всех таблиц хранятся в одной таблице versions (table_name text, data jsonb, inserted_at timestamp). Плюс — не нужно создавать новую таблицу *_history для каждой таблицы, у которой ты хочешь отслеживать версии. Явный минус — нельзя навесить внешние ключи.

У каждого варианта есть свои минусы, серьёзность которых будет зависеть от используемой СУБД и типовых запросов, которые ты в своём приложении будешь выполнять со этими данными.