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

Question

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

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

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

Answer 1

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

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

РЕДАКТИРОВАТЬ: Мысль о другом несоответствии - Если у вас есть уникальные индексы в таблице, удаленные записи по-прежнему будут занимать «одну» запись, поэтому вам придется кодировать эту возможность тоже (например, таблица пользователя, которая имеет уникальный индекс для имени пользователя; удаленная запись будет по-прежнему блокировать имя пользователя для удаленных пользователей для новых записей. Обойдя это, вы можете привязать GUID к столбцу удаленного имени пользователя, но это очень хакерский обходной путь, который я бы не рекомендовал. В этом случае было бы лучше иметь правило, согласно которому после использования имени пользователя его нельзя заменить.)

Answer 2

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

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

Недостатки включают (не включая другие, уже упомянутые):

1. Производительность. Сохранение всех этих данных. Мы разрабатываем различные стратегии архивирования. Например, одна область приложения была близка к генерированию около 1 ГБ данных в неделю.
2. Стоимость хранения данных со временем растет, в то время как дисковое пространство дешевое, объем инфраструктуры для хранения и управления терабайтами данных как в режиме онлайн, так и в автономном режиме очень велик. Для обеспечения избыточности требуется много дискового пространства, а для обеспечения быстрого перемещения резервных копий требуется время.

Принимая решение об использовании логических, физических удалений или архивации, я задавал себе следующие вопросы:

1. Являются ли эти данные, которые, возможно, потребуется повторно вставить в таблицу. Например, учетные записи пользователей соответствуют этой категории, поскольку вы можете активировать или деактивировать учетную запись пользователя. Если это так, то логическое удаление имеет смысл.
2. Есть ли какая-то внутренняя ценность в хранении данных? Если да, то сколько данных будет сгенерировано. В зависимости от этого я либо выбрал бы логическое удаление, либо реализовал бы стратегию архивирования. Имейте в виду, что вы всегда можете архивировать логически удаленные записи.

Answer 3

Возможно, уже немного поздно, но я советую всем проверить Сообщение в блоге Пинала Дейва о логическом / мягком удалении:

Мне просто не нравится этот вид дизайна [мягкое удаление] вообще. Я твердо верю в архитектуру, где только необходимые данные должны быть в одной таблице, а бесполезные данные должны быть перемещены в архивную таблицу. Вместо того, чтобы следовать столбцу isDeleted, я предлагаю использовать две разные таблицы: одну с заказами и другую с удаленными заказами. В этом случае вам придется поддерживать оба стола, но в действительности это очень легко поддерживать. Когда вы пишете инструкцию UPDATE в столбец isDeleted, пишите INSERT INTO другой таблицы и УДАЛЯЙТЕ ее из исходной таблицы. Если ситуация с откатом, напишите еще один INSERT INTO и DELETE в обратном порядке. Если вы беспокоитесь о неудачной транзакции, поместите этот код в транзакцию.

В чем преимущества таблицы меньших по сравнению с таблицей большего размера в описанных выше ситуациях?

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

Answer 4

Я разработчик NoSQL, и на своей последней работе я работал с данными, которые всегда были важны для кого-то, и, если они были случайно удалены в тот же день, что и я, я не смог найти их в последняя резервная копия со вчерашнего дня! В этой ситуации мягкое удаление всегда сохраняло день.

Я сделал мягкое удаление, используя временные метки, зарегистрировав дату, когда документ был удален:

IsDeleted = 20150310  //yyyyMMdd

Каждое воскресенье процесс проходил по базе данных и проверял поле IsDeleted. Если разница между текущей датой и отметкой времени была больше, чем N дней, документ трудно удалить. Учитывая, что документ по-прежнему доступен в некоторой резервной копии, это было безопасно сделать.

РЕДАКТИРОВАТЬ: Этот сценарий использования NoSQL касается больших документов, создаваемых в базе данных, десятки или сотни из них каждый день, но не тысячи или миллионы. В целом это были документы со статусом, данными и приложениями рабочих процессов. Это было причиной, по которой пользователь мог удалить важный документ. Этим пользователем может быть кто-то с правами администратора или владелец документа, и это только некоторые из них.

TL; DR Мой вариант использования не был большими данными. В этом случае вам потребуется другой подход.

Answer 5

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

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

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

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

Какие еще преимущества? - замечательно, если у вас есть куча кодеров, работающих над проектом, выполняющих чтение в базе данных со смешанными навыками и вниманием к уровням детализации, вам не нужно не спать по ночам надеясь, что один из них не забудет не включать удаленные записи (lol, Not Include Deleted Records = True), что приводит к таким вещам, как завышение, скажем, наличие у клиента наличной позиции, с которой они затем покупают некоторые акции (то есть, как в торговая система), когда вы работаете с торговыми системами, вы очень быстро узнаете ценность надежных решений, даже если они могут иметь немного больше первоначальных «накладных расходов».

Исключения:
- в качестве руководства используйте мягкое удаление для «справочных» данных, таких как пользователь, категория и т. д., и жесткое удаление в зеркальной таблице для данных «фактического» типа, то есть истории транзакций.

Answer 6

Я почти всегда мягко удаляю и вот почему:

• вы можете восстановить удаленные данные, если клиент попросит вас сделать это. Больше счастливых клиентов с программным удалением. Восстановление определенных данных из резервных копий является сложным
• проверка на isdeleted везде не является проблемой, вы все равно должны проверить на userid (если база данных содержит данные от нескольких пользователей). Вы можете применить проверку по коду, поместив эти две проверки в отдельную функцию (или используйте представления)
• Изящное удаление. Пользователи или процессы, имеющие дело с удаленным контентом, будут продолжать «видеть» его, пока не достигнут следующего обновления. Это очень желательно, если процесс обрабатывает некоторые данные, которые внезапно удаляются
• синхронизация: если вам нужно разработать механизм синхронизации между базой данных и мобильными приложениями, вы обнаружите, что программные удаления гораздо проще реализовать

Answer 7

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

Это работает хорошо, потому что у вас все еще есть данные, если вы когда-либо проверяли. Если вы удалите его физически, оно исчезнет !

Answer 8

Я большой поклонник логического удаления, особенно для приложения Line of Business или в контексте учетных записей пользователей. Мои причины просты: часто я не хочу, чтобы пользователь мог больше использовать систему (поэтому учетная запись помечается как удаленная), но если мы удалим пользователя, мы потеряем всю его работу и все такое.

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

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

Answer 9

Re: "Это безопасно?" - это зависит от того, что вы имеете в виду.

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

Если вы имеете в виду, что при логическом удалении ваши данные более безопасны, потому что вы никогда не потеряете данные , это тоже верно. Это хорошо для сценариев аудита; Я склонен проектировать этот способ, потому что он допускает основной факт, что после того, как данные сгенерированы, они никогда не исчезнут (1009 * действительно * 1010) (особенно, если они когда-либо имели возможность, скажем, кэшироваться поисковой системой в Интернете). ). Конечно, реальный сценарий аудита требует не только логического удаления, но и того, что обновления также регистрируются вместе со временем изменения и актером, который внес изменение.

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

Answer 10

Существуют требования, помимо проектирования системы, на которые необходимо ответить. Каковы юридические или законодательные требования в отношении хранения записей? В зависимости от того, с чем связаны строки, может существовать законное требование, чтобы данные хранили в течение определенного периода времени после того, как они «приостановлены».

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