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

Question

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

0

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

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

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

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

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

UserJ 19 май 2018, в 19:30

Источник

0

Просто сделайте обычную таблицу с настройками. Всякий раз, когда вы вставляете / обновляете, вы сразу после этого также > добавляете <строку в таблицу истории ( user_settings 2 таблицы user_settings и user_settings_history ) с точно такими же значениями. Таким образом, у вас автоматически будет таблица истории с последней записью, ТАКЖЕ текущей и таблицей только с текущими значениями. Добавьте поле «измененный» в таблицу истории (и «измененный_бай» и т. Д.) Для получения более важной исторической информации, которая может быть полезна позже.
RobIII 19 май 2018, в 16:50

Теги:

mysql

sql

1 ответ

Ещё вопросы

Просто сделайте обычную таблицу с настройками. Всякий раз, когда вы вставляете / обновляете, вы сразу после этого также > добавляете <строку в таблицу истории ( user_settings 2 таблицы user_settings и user_settings_history ) с точно такими же значениями. Таким образом, у вас автоматически будет таблица истории с последней записью, ТАКЖЕ текущей и таблицей только с текущими значениями. Добавьте поле «измененный» в таблицу истории (и «измененный_бай» и т. Д.) Для получения более важной исторической информации, которая может быть полезна позже.

Bill Karwin · Answer 1 · 2018-05-19T14-24-00.000Z

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

Когда создается параметр, вставьте его в таблицу user_settings_history вместе с отметкой времени, когда она была создана. Затем также UPDATE те же настройки в таблице user_settings. В user_settings будет одна строка для каждого пользователя, и она всегда будет текущими настройками.

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

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

Если вы обеспокоены тем, что таблица user_settings_history становится слишком большой, столбец timestamp позволяет довольно легко периодически удалять строки старше 180 дней или любое количество дней кажется вам подходящим.

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