Физическое или логическое / мягкое удаление записи базы данных?

Question

В чем преимущество логического / мягкого удаления записи (т. Е. Установки флажка, указывающего, что запись удалена) по сравнению с фактическим или физическим удалением записи?

Это обычная практика?

Это безопасно?

Answer 1

Раньше я делал мягкое удаление, просто чтобы сохранить старые записи. Я понял, что пользователи не удосуживаются просматривать старые записи так часто, как я думал. Если пользователи хотят просматривать старые записи, они могут просто просматривать из архива или таблицы аудита, верно? Итак, в чем преимущество soft-delete? Это приводит только к более сложному запросу и т. Д.

Ниже приведены вещи, которые я реализовал, прежде чем я решил больше не удалять софт:

1. внедрить аудит, чтобы записывать все действия (добавлять, редактировать, удалять). Убедитесь, что внешний аудит не связан с аудитом, и убедитесь, что эта таблица защищена и никто не может удалить ее, кроме администраторов.

2. определяет, какие таблицы считаются «транзакционными таблицами», что весьма вероятно, что они будут храниться в течение длительного времени, и очень вероятно, что пользователь может захотеть просмотреть прошлые записи или отчеты. Например; сделка покупки Эта таблица должна не только содержать идентификатор главной таблицы (такой как dept-id), но также хранить дополнительную информацию, такую ​​как имя в качестве ссылки (например, dept-name), или любые другие необходимые поля для отчетов.

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

Только мое мнение в два цента.

Answer 2

Мобильные приложения, зависящие от синхронизации, могут навязывать логическое, а не физическое удаление: сервер должен иметь возможность указать клиенту, что запись была (помечена как) удалена, и это может быть невозможно, если записи физически удален.

Answer 3

Логические удаления, если сложно ссылочной целостности.

Это правильное решение, если есть временные аспекты данных таблицы (допустимы FROM_DATE - TO_DATE).

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

С положительной стороны:

Это более простой способ отката (если это вообще возможно).

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

Answer 4

Я категорически не согласен с логическим удалением, поскольку вы подвержены множеству ошибок.

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

Вторая производительность: представьте таблицу с 100000 записей только с 3 активными, теперь умножьте это число на таблицы вашей базы данных; Еще одна проблема с производительностью - возможный конфликт с новыми записями со старыми (удаленными записями).

Единственное преимущество, которое я вижу, - это история записей, но есть и другие способы достижения этого результата, например, вы можете создать таблицу регистрации, в которой вы можете сохранить информацию: TableName,OldValues,NewValues,Date,User,[..], где *Values Можно varchar и записать детали в этой форме fieldname : value; [..] или сохраните информацию как xml.

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

Answer 5

Это довольно стандартно в тех случаях, когда вы хотите вести историю чего-либо (например, учетные записи пользователей, как упоминает @Jon Dewees). И это, безусловно, хорошая идея, если есть большая вероятность того, что пользователи будут требовать удаления.

Если вас беспокоит логика фильтрации удаленных записей по вашим запросам, которая становится беспорядочной и просто усложняет ваши запросы, вы можете просто создать представления, которые выполняют фильтрацию для вас, и использовать запросы против этого. Это предотвратит утечку этих записей в отчетах и ​​т. Д.

Answer 6

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

Я говорю о нашей реализации на python и аналогичном сценарии использования, который мы затронули.

Мы столкнулись с https://github.com/kvesteri/sqlalchemy-continuum, который представляет собой простой способ получить таблицу версий для соответствующей таблицы. Минимальное количество строк кода и история событий для добавления, удаления и обновления.

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

Таким образом, нам вообще не нужно было столбец is_deleted, и наша функция удаления была довольно тривиальной. Таким образом, нам также не нужно помнить, чтобы пометить is_deleted=False в любом из наших API.

Answer 7

Они не позволяют базе данных работать должным образом, что делает такие вещи, как каскадные функции, бесполезными.

Для простых вещей, таких как вставки, в случае повторной вставки код позади нее удваивается.

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

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

Я не большой поклонник логических удалений.

Answer 8

Все зависит от варианта использования системы и ее данных.

Например, если вы говорите о регулируемой государством системе (например, о системе в фармацевтической компании, которая считается частью системы качества и должна следовать руководящим принципам FDA для электронных записей), то вы чертовски хорошо, лучше не делать усердно удаляет! Аудитор из FDA может прийти и запросить все записи в системе, относящиеся к номеру продукта ABC-123, и все данные лучше будут доступны. Если владелец вашего бизнес-процесса говорит, что система не должна позволять кому-либо использовать номер продукта ABC-123 для новых записей в будущем, используйте метод мягкого удаления, чтобы сделать его «неактивным» в системе, сохраняя при этом исторические данные.

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

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

Answer 9

Чтобы дать альтернативу, у нас есть пользователи, использующие удаленные устройства, которые обновляются через MobiLink. Если мы удаляем записи в базе данных сервера, эти записи никогда не помечаются как удаленные в базах данных клиента.

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

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

Мы не столько о безопасности данных, сколько о наличии огромных баз данных на клиентском устройстве с ограниченной памятью, например на смартфоне. У клиента, который заказывает 200 продуктов два раза в неделю в течение четырех лет, будет более 81 000 строк истории, из которых 75% клиенту все равно, увидит ли он.

Answer 10

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

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

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

С точки зрения безопасности SoftDelete не заменит работу аудита и не заменит работу резервного копирования. Если вы боитесь «вставить / удалить между двумя резервными копиями», вам следует прочитать о моделях полного или массового восстановления. Я признаю, что SoftDelete мог бы сделать процесс восстановления более тривиальным.

До вас, чтобы знать ваши требования.