2014-02-17 4 views
0

Мне нужно вести записи для сущностей в моей СУБД, даже если пользователь удаляет какой-либо объект из переднего конца. Скажем, у меня есть таблица пользователей, в которой каждый пользователь имеет уникальное электронное письмо. Теперь скажите, что пользователь с именем name1 имел электронное письмо email1. Теперь пользовательская запись удаляется из внешнего интерфейса, и кто-то пытается создать пользователя с name2 и по электронной почте email1. Это нарушит единственное ограничение на столбец email, но мне все равно нужно сохранить эту запись в этой таблице, поэтому в моей таблице есть столбец с именем status, значением по умолчанию которого является 1. Теперь у меня есть уникальное ограничение на email и status. Всякий раз, когда кто-то удаляет пользователя, я увеличиваю его статус на 1. Но это имеет проблему в случае, когда запись пользователя с адресом электронной почты email1 удаляется дважды. В этом случае у меня будет 2 записи пользователя со статусом 2. Так что этот метод терпит неудачу. Другой способ - переместить удаленные записи в другую таблицу, которая не имеет ограничений любого типа. Но, используя этот подход, мне нужно иметь дополнительную таблицу для каждой таблицы, для которой мне нужно отслеживать удаленные записи. Поэтому я нахожу эту глупость. Любой другой способ решить эту проблему?лучший способ отметить удаленные записи в СУБД

+0

В вашем приложении при доступе к электронной почте проверьте, если status => 1, тогда рассмотрите его удалил – xrcwrn

+0

@xrcwrn да, я могу это сделать, но для этого мне нужно прочитать. Я хочу сделать это без чтения и использования уникального ограничения. – lovesh

ответ

0

Я бы предложил использовать столбец временной метки вместо номера, чтобы сохранить удаленный статус, потому что обычно требуется информация о времени. Он известен как временная модель и обычно использует две временные метки для определения интервала допустимости http://en.wikipedia.org/wiki/Temporal_database Модель Anchor расширяет эту модель со специальными понятиями: Якорь, уровень, узел, атрибут http://en.wikipedia.org/wiki/Anchor_Modeling На самом деле все временные модели имеют много проблем в регулярных реализациях РСУБД, эта проблема адресуется в SQL 2012, но в средние сроки он широко не внедряется, и поставщики RDBMS предоставляют очень разные решения, например, «Захват данных» или «Flashback».

+0

Официально корректное название последней версии стандарта SQL - «SQL: 2011», а не «SQL 2012». http://en.wikipedia.org/wiki/SQL:2011. –

Смежные вопросы