Лучший способ хранить удаленные данные пользователя? - PullRequest
5 голосов
/ 21 декабря 2011

Я работаю над приложением, которое отслеживает и обрабатывает рабочие задания / заявки. Каждый тикет связан с пользователем, который создает / владеет тикетом через внешний ключ, который каскадирует любые изменения в MySQL. Очевидно, что если бы пользователь по какой-либо причине удалил свою учетную запись, мы все равно хотели бы вести учет его билетов и их основной информации.

Первый способ сделать это, пришедший на ум, - это иметь столбец в таблице пользователей, который обозначает, активны они или нет, то есть удалены или нет. Таким образом, когда они закрывают / удаляют свою учетную запись, они просто переворачивают это значение и затем не могут получить доступ к приложению.

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

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

Ответы [ 2 ]

10 голосов
/ 21 декабря 2011

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

Хорошо.

У меня была еще одна идея - перенести запись пользователя в таблицу удаленных пользователей.

Bad. Теперь у вас есть два объединения: пользователь в билет и бывший пользователь в билет. Это ненужная сложность.

может стать огромной сделкой, когда она станет большой,

Если под "большим" вы подразумеваете миллионы пользователей, то вы правы. Однако, если под «большим» вы подразумеваете тысячи пользователей, вы не сможете измерить большую разницу.

А. Если в будущем у вас действительно будет заметное замедление, вы можете использовать такие вещи, как «материализованные представления», чтобы автоматически создавать подмножество представления / таблицы «активных» пользователей.

Очевидно, что частью этого может быть предпочтение,

Не совсем. Деактивация (но не удаление) пользователей имеет многочисленные преимущества и никаких реальных недостатков.

Существует множество уровней активности - блокировка безопасности (но не отключена) - временно отключена - делегирована другим пользователям. Много-много изменений статуса. Несколько причин для удаления. Нет причин для «перехода к другому столу».

Как запрос на выборку сравнивается с запросом на вставку и в какой момент общая производительность возрастет, если добавить в запрос запросы на вставку (перемещение записей в таблицу удаленных пользователей)?

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

1 голос
/ 21 декабря 2011

На мой взгляд, лучше всего пометить пользователя как удаленного или нет.Второй способ, с новой таблицей, будет вызывать изменения в каждой таблице, где вы ссылаетесь на таблицу пользователей.У вас должен быть новый внешний ключ для «таблицы удаленных пользователей».Это изменит все запросы для строк выбора из этих таблиц.

Как вы писали, приложение относится к тикетам, логически большинство запросов будет касаться выбора и редактирования тикетов.Таким образом, влияние будет на эту таблицу, я не думаю, что вы делаете большие запросы о пользователях.

Оптимизация для таблицы "user" и выполнение более сложных запросов для таблицы "ticket" не окупятся.

...