стратегии архивирования и ограничения данных в таблице

Question

Среда: Jboss, Mysql, JPA, Hibernate

Наше веб-приложение будет обслуживать большое количество пользователей (~ 1 000 000), и существует множество дочерних таблиц, в которых хранятся данные, относящиеся к конкретным пользователям (например, личные данные, сведения о здоровье, вклад в форумы ...).

1. Что было бы лучшим способом архивировать информацию о пользователях и пользователях. [a] Было бы целесообразно переместить заархивированную информацию о пользователях и пользователях в соответствующие таблицы в одной и той же базе данных (например, user_archive, user_forum_comments_archive ...) ИЛИ [b] Вы просто отметили бы записи базы данных с флагом в исходной таблице (таблицах) и просто запросили только неархивированные записи.

2. У нас есть уникальное ограничение на User.loginid, как вы справляетесь с этим требованием, если пользователи архивируются через 1- [a] (т.е. если пользователь с логином 'samuel' перемещается в архивную таблицу и Если новый пользователь будет добавлен с тем же именем в исходной таблице, как бы вы это предотвратили. Какова была бы лучшая стратегия для устранения ограничений уникального ключа.

3. У нас есть требование выборочно архивировать записи и возвращать их при необходимости, будете ли вы полагаться на инструменты базы данных, если бы вы справились с этим через свои API персистентности, предоставляемые моделью сущностей JPA.

Answer 1

Лично я бы пошел на решение "[a]".

Разделение элементов на два набора таблиц (текущее и архивированное) усложнит управление с точки зрения общих концепций СУБД (пример: автор комментариев на форуме будет внешним ключом, указывающим на таблицу пользователя ... но вы не может иметь поле, которое ведет себя как внешний ключ для двух разных таблиц).

Вы могли бы пойти на компромисс (таблица пользователей использует решение "a", все другие таблицы, такие как профиль, архивируются в двойную таблицу, как для решения "b"), но это усложнит ваш код (в некоторых случаи, в которых вы должны смотреть на неархивированные, в некоторых только на архивные, в некоторых других на объединение обоих).

Решение A также легко решило бы требования № 2 и № 3. Уникальность имени пользователя легко реализовать, если все находится в одной таблице, а воскрешение заархивированных пользователей - это всего лишь вопрос переключения (Archived = Y / N) на главную таблицу пользователей.

10% не так много, я сомневаюсь, что разница в производительности действительно оправдает дополнительную сложность (и риск ошибок).

Answer 2

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