Скажем, у меня две таблицы, user
и comment
. У них есть определения таблиц, которые выглядят так:
CREATE TABLE `user` (
`id` INTEGER NOT NULL AUTO_INCREMENT,
`username` VARCHAR(255) NOT NULL,
`deleted` TINYINT(1) NOT NULL DEFAULT 0,
PRIMARY KEY (`id`),
UNIQUE KEY (`username`)
) ENGINE=InnoDB;
CREATE TABLE `comment` (
`id` INTEGER NOT NULL AUTO_INCREMENT,
`user_id` INTEGER NOT NULL,
`comment` TEXT,
`deleted` TINYINT(1) NOT NULL DEFAULT 0,
PRIMARY KEY (`id`),
CONSTRAINT `fk_comment_user_id` FOREIGN KEY (`user_id`)
REFERENCES `user` (`id`)
ON DELETE CASCADE
ON UPDATE CASCADE
) ENGINE=InnoDB;
Это отлично подходит для обеспечения целостности данных и всего этого, но я хочу, чтобы иметь возможность "удалять" пользователя и хранить все его комментарии (для справки).
С этой целью я добавил deleted
, чтобы я мог SET deleted = 1
записать. Перечисляя все с помощью deleted = 0
по умолчанию, я могу скрыть все удаленные записи, пока они мне не понадобятся.
Пока все хорошо.
Проблема возникает, когда:
- Пользователь подписывается с именем пользователя (скажем, "Сэм" ),
- Я мягко удаляю этого пользователя (по независящим причинам) и
- Кто-то еще приходит, чтобы зарегистрироваться как Сэм, и внезапно мы нарушили ограничение UNIQUE на
user
.
Я хочу, чтобы пользователи могли редактировать собственные имена пользователей, поэтому я не должен делать username
первичный ключ, и при удалении пользователей у нас будет такая же проблема.
Любые мысли?
Изменить для пояснения: Добавлены следующие ответы и комментарии RedFilter ниже.
Я занимаюсь тем случаем, когда "удаленные" пользователи и комментарии не видны публике, но видны только администраторам или хранятся с целью расчета статистики.
Этот вопрос представляет собой мысленный эксперимент, при этом таблицы пользователей и комментариев просто являются примерами. Тем не менее, username
был не лучшим для использования; RedFilter делает достоверные данные о личности пользователя, особенно когда записи представлены в общедоступном контексте.
Относительно "Почему имя пользователя не является первичным?": это всего лишь пример, но если я применил это к реальной проблеме, мне нужно будет работать в рамках ограничений существующей системы, предполагающей существование суррогатный первичный ключ.