Я придумал эту структуру SQL, чтобы позволить откатывать и проверять информацию о пользователях, будет ли этого достаточно?

Question

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

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

Изображение схемы

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

Правильно ли я выбрал эту модель?Есть ли другой способ сделать это?

Answer 1

Я бы также использовал вторую таблицу user_settings_history.

Когда параметр создан, ВСТАВЬТЕ его в таблицу user_settings_history вместе с отметкой времени его создания.Затем также ОБНОВИТЕ те же настройки в таблице user_settings.В user_settings для каждого пользователя будет одна строка, и это всегда будут текущие настройки.

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

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

Если вы обеспокоены тем, что таблица user_settings_history становится слишком большой, столбец отметки времени позволяет довольно легкоПериодически УДАЛЯЙТЕ строки старше 180 дней, или любое другое количество дней, которое вам кажется подходящим.

Кстати, 5 миллионов строк не так велики для базы данных MySQL.Вы бы хотели, чтобы ваши запросы использовали индекс там, где это необходимо, но один только размер не является недостатком.