Пометка удаленных записей в таблицах БД

Question

Иногда вы хотите пометить запись таблицы БД как удаленную, а не удалять ее навсегда, верно?

Как ты это делаешь?

До сих пор я использовал логическое «удаленное» поле, но я не уверен, что это хорошая оценка.

Answer 1

Вот и все - логическое поле, указывающее, что запись удалена. Несколько раз я использовал это, я назвал это поле IsDeleted.

Это часто называют Логическое удаление .

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

Кроме того, вы можете столкнуться с некоторыми проблемами, если у вас есть уникальные ограничения для таблицы. Например, если в пользовательской таблице у пользователя есть IsDeleted = true, а столбец электронной почты уникален, я не смог бы добавить нового пользователя с тем же адресом электронной почты.

Есть некоторые ORM, которые принимают во внимание эти поля - например, SubSonic 2.2 не удалит запись, если есть столбец с именем «Удален» или «IsDeleted», вместо этого он установит для этого поля значение true.

Некоторые связанные ресурсы:

• Физическое или логическое / мягкое удаление записи базы данных?
• Должен ли я удалить или отключить строку в реляционной базе данных?
• Работа с «удаленными» строками SubSonic
• ORM & Logical Delete

В качестве альтернативы вы можете добавить таблицы аудита.

Answer 2

Я обычно использую IsDeleted.

Если имеется несколько состояний (например, нормальное, архивное, удаленное), я мог бы использовать Enum (или Int, если он недоступен) для представления состояния. Обычно я бы назвал поле Status или State в этом случае.

Answer 3

Я бы использовал datetime, null для живого, timstamp для "удаленного вкл."

Answer 4

В банковской отрасли считается хорошей практикой хранить все модификации (а не только удаления). Обычно это делается в «таблицах журналов» с почти тем же DDL, что и исходный плюс несколько флагов, указывающих тип операции, дату и время, пользователя и т. Д. НО (ОЧЕНЬ важно) таблицы журналов определены БЕЗ уникальных ключей!

Answer 5

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