Является ли софт удаляет хорошую идею? [Дубликат]

Я говорю, что это плохая идея, в целом (с некоторыми исключениями, возможно).

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

Во-вторых, такое мягкое удаление означает, что вам теперь придется включать WHERE IsDeleted = false в каждый запрос к этой таблице (и намного хуже, если вы соединяете эти таблицы). Ошибка здесь будет обнаружена сразу же, как только пользователь или тестировщик заметит, что удаленная запись снова появилась, что может занять некоторое время. Кроме того, разработчику будет легко опустить предложение WHERE в запросах COUNT(*), что может занять еще больше времени (я работал над одним проектом, где это происходило годами; не так много записей было "удалено", поэтому итоговые значения были близки к ожидаемым, и никто этого не заметил).

Наконец, мягкое удаление будет работать в таблице с искусственными ключами, но потенциально не будет работать в таблице с естественным первичным ключом (например, вы "удаляете" кого-то из таблицы с ключом по номеру социального страхования - что вы будете делать, когда вам понадобится добавить его обратно? Пожалуйста, не говорите "включите IsDeleted в составной первичный ключ").

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

Я столкнулся с мягким удалением для следующих широких сценариев:

СЛУЧАЙ 1: удалить запись из видимости пользователя / кода, но сохранить запись в уровень БД, поскольку бизнес заинтересован в том, чтобы знать, что у него есть эти записи.
Эти требования в основном обусловлены бизнесом, и обычно в основе, возможно, лежит юридическое требование (например, сценарии @joshperry и @armandino) иметь предыдущую запись в базе данных и создавать новую запись для каждого изменение сделано. На этом этапе я бы посмотрел на СЛУЧАЙ 2 и оценил, удовлетворяет ли он требованиям, прежде чем иметь флаг IsDeleted

СЛУЧАЙ 2: контрольные журналы для отслеживания эволюции записи - в Интернете есть множество достойных статей для ведения аудита следы записей в базе данных

HTH.

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

Кроме того, я сохраняю дату, время и имя редакции для каждого объекта, чтобы я знал, кто изменил (или произвольно удалил) его последним. Затем для контрольного журнала я создаю таблицу * History (например, CustomerHistory), которая вставляется после каждого ОБНОВЛЕНИЯ исходной таблицы. Таким образом, после изменения или мягкого удаления объекта у меня есть запись о том, кто выполнил действие, а также последнее известное состояние объекта.

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

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

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

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

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

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

Это зависит от данных. Некоторые данные не могут быть удалены из-за требований законодательства / аудита.

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

Иногда необходимо мягкое удаление. Например, у вас есть таблица Invoice, которая ссылается на таблицу Products. Создав счет-фактуру с определенным продуктом, вы никогда не сможете удалить этот продукт (и если ваш RI настроен правильно, он не позволит вам этого сделать).

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

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

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

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

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

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

В противном случае, я думаю, это хорошая идея.

Никогда не помешает избежать потенциальной потери данных.

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

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

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

в oracle: если вы добавите первичный ключ в составленную вами таблицу recycle_bin, а затем добавите политику безопасности на уровне строки, вы можете подавить значения из всех запросы, когда строка находится в корзине, удаление pk из корзины автоматически восстановит все данные. нет необходимости изменять другие запросы, чтобы соответствовать логике.