Является ли мягкое удаление хорошей идеей или плохой идеей?
Вместо фактического удаления записи в вашей базе данных вы просто укажете ее как IsDeleted = true, а после восстановления записи вы можете просто отметить ее как False.
Это хорошая идея?
Лучше ли вы физически удалить запись, а затем переместить ее в архивную базу данных, и если пользователь хочет вернуть запись, тогда программное обеспечение будет искать запись в архиве и воссоздать ее?
Я говорю это плохая идея, вообще (с некоторыми исключениями, возможно).
Во-первых, ваша база данных должна быть скопирована регулярно, поэтому вы никогда не должны находиться в ситуации, когда вы потеряете данные навсегда из-за DELETE (если только это не приведет к удалению только что добавленных данных, конечно).
Во-вторых, мягкое удаление, подобное этому, теперь вам нужно включить предложение WHERE IsDeleted = false в каждый запрос в этой таблице (и тем хуже, если вы присоединяетесь к этим таблицам). Ошибка здесь была бы поймана, как только пользователь или тестер заметил, что удаленная запись снова появится, что может занять некоторое время. Кроме того, разработчику было бы легко опустить предложение WHERE из запросов COUNT (*), что может занять еще дольше (я работал над одним проектом, где это происходило в течение многих лет, а не так много записей "удалялось" ), поэтому итоговые значения были близки к ожидаемому, и никто не заметил).
Наконец, мягкое удаление будет работать с таблицей с искусственными ключами, но потенциально не будет работать в таблице с естественным первичным ключом (например, вы "удаляете" кого-либо из таблицы с номером социального обеспечения - что вы когда вам нужно добавить его обратно? Пожалуйста, не говорите: "Включите IsDeleted в составной первичный ключ".).
В обзоре дизайна я ожидал бы, что разработчик продемонстрирует осознание затрат и преимуществ и предоставит отличную причину для мягких удалений таким образом. "Почему бы не сделать это?" не является отличной причиной.
Это никогда не будет плохой идеей, чтобы избежать потери данных.
Я всегда soft-delete. В тех случаях, когда необходимо очистить базу данных от одной или нескольких записей, я обычно использую двухэтапный процесс мягкого удаления и затем опорожнения "корзины" записей или подход, основанный на стиле документа, когда записи документа могут быть в возрасте, а затем пройти процесс утверждения до жесткого удаления.
Это зависит от обстоятельств. Я мог видеть ситуации, когда вам по закону требуется действительно что-то удалить. Возможно, кто-то попросил, чтобы их номер социального страхования был окончательно удален из вашей системы. Или, может быть, у вас есть дублирующаяся запись, которую вы хотите консолидировать в одну запись. Сохранение дубликата, зависающего с удаленным флагом, может оказаться нецелесообразным.
Существует также один технический недостаток: вы не можете выполнять каскадные удаления, которые автоматически удаляют любые ссылки на удаленные данные, чтобы предотвратить нарушения внешнего ключа. Это не обязательно большая проблема, но это то, что нужно иметь в виду.
В противном случае, я думаю, это хорошая идея.
Если вы собираетесь использовать мягкое удаление, рекомендуется иметь поле deleted_date вместо поля is_deleted. Вы получаете хороший кусок дополнительных данных, а не только поле бит.
Одной из основных проблем для мягкого удаления является то, что нежелательные данные потенциально влияют на производительность db. Несколько лет назад один из моих клиентов попросил меня сделать мягкое удаление во всех элементах базы данных, мое решение - переместить все "удаленные" элементы в таблицу резервного копирования вместо того, чтобы оставлять их в текущих текущих таблицах.
Это хорошая идея, когда и если недействительное удаление абсолютно катастрофично, а восстановление должно быть простым. Это также хорошая идея, если вы хотите отслеживать все, что когда-либо было и "удалять" на самом деле означает только "скрыть". Значит, это зависит от ситуации.
Мягкие удаления также позволят вам revoke DELETE привилегии из учетной записи базы данных, используемой приложением.
Я не буду пытаться "политически корректно". Если вы защищаете soft-delete, вам нужно пойти на проверку мозга.
1) Во-первых, что именно вы достигаете, не удаляя строки в таблице? Просто тот факт, что когда-нибудь в будущем вы сможете получить доступ к этим строкам, не так ли? Так почему бы не просто создать архивную таблицу и переместить там строки? что с этим не так?
2) С помощью soft-delete вы создаете ненужный запрос на is_active или запрос в какой-либо колонке с отметкой времени. Это просто отходы, когда вы будете писать более простые запросы. Да, он будет работать с представлением, но не является дополнительным придатком? Каждое представление представляет собой дополнительный SQL, дополнительные затраты на производительность, вниз в любой коммерческой СУБД, все это только таблица. Нет ничего волшебного в отношении взглядов, кроме того, что вы не знаете, как писать запросы поверх таблиц.
3) Да, он будет работать с View или MV. Но потом я видел запросы в производстве, делающие FTS, и все еще работает! Чудеса современного оборудования и прочного программного обеспечения. Но тогда это тоже не подходит. Таким образом, по той же логике, только потому, что она работает, это не значит, что она ПРАВО
4) Сложности мягкого удаления никогда не останавливаются при простом выборе.
A) Предположим, что у вас есть ограничение UNIQUE. Теперь вы мягко удаляете строку, но столбец с ограничением UNIQUE все еще существует. Если вы хотите добавить те же данные обратно, вы не сможете этого сделать без дополнительных "трюков".
B) У вас могут быть ассоциации, идущие из таблицы A в таблицу B, и когда вы мягко удаляете что-либо из таблицы A, вам необходимо убедиться, что независимые запросы в таблице B позаботятся об этом факте. Предположим, что на странице detail_id была написана типичная подробная страница.
Теперь master_id мягко удален, но у вас все еще есть permalinks с detail_id этого master_id. Когда вы выполняете жесткое удаление на master_id, эти данные просто не существуют. Теперь с мягким удалением они все еще существуют, и они должны знать о том, что их master_id находится в режиме мягкого удаления.
он не остановится на простой Table_A.is_active = 0 или 1 стадии.
5) Выполнение жестких удалений является простым и правильным.
A) Никто не должен ничего добавлять или беспокоиться ни о чем.
Просто скопируйте данные + связанные фрагменты, и вы должны быть хорошими.
Иногда требуется мягкое удаление. Например, скажем, что у вас есть таблица счетов, которая ссылается на таблицу Products. После того, как вы создали счет-фактуру с определенным продуктом, вы никогда не сможете удалить этот продукт (и если ваш RI настроен правильно, он не позволит вам).
В этом конкретном сценарии предполагается, что вы никогда не захотите удалить счета-фактуры, которые в реальной компании вы, вероятно, не захотите удалять исторические финансовые данные.
Хотя есть много других случаев, когда вы не сможете удалить некоторые данные в качестве побочного эффекта зависимости от цепочки, которая не может быть удалена по причинам бизнеса или другим.
Это зависит от данных. Некоторые данные не могут быть удалены из-за требований законодательства/аудита.
С другой стороны, сайты социальных сетей должны предоставлять возможность удалять учетную запись со всеми связанными данными, включая контактную информацию, фотографии, сообщения и т.д. Это реальная досада, если они этого не делают, например Facebook.
в oracle, если вы добавите первичный ключ в таблицу recycle_bin, которую вы составляете, затем добавьте политику безопасности на уровне строк, вы можете подавить значения из всех запросов, когда строка находится в корзине, удалив pk из корзина будет автоматически восстанавливать все данные. не нужно менять ваши другие запросы, чтобы разместить логику.
Он поставляется со стоимостью, хотя, поскольку вам нужно обновить свои запросы и индексы, чтобы иметь возможность исключать удаленные строки.
Возможно, вместо того, чтобы переключать флаг, переместите его в другую таблицу "Корзина мусора".
Кроме того, можно сказать, что это лишь частичное решение, потому что оно охватывает только удаляет, но когда вы обновляете строку, вы по-прежнему перезаписываете старое значение.
В общем, я бы сказал, никогда ничего не удаляю, если вам действительно не нужно. В наши дни дисковое пространство дешево. Конечно, существуют ограничения, есть данные, которые вы юридически обязаны стирать, есть данные, которые действительно не так важны, и, возможно, вам не нужно хранить старые данные в Интернете и в одной таблице (где-то в архиве также будет работать).
Просто добавьте цент. Я всегда soft-delete; хотя это действительно стоило производительности, но очень немного. Подумайте о стоимости, когда ваш клиент жалуется на ваше программное обеспечение, которое перестало функционировать после того, как она выполнила определенные действия, которые она даже не может запомнить. Ну, это может быть толстый пример, но вы никогда не узнаете, что пошло не так, кто что сделал, что было раньше и что было вставлено потом. В этом случае это будет удобно. Эта функция удобна для целей аудита, и многие запросы клиентов для аудита отчетов такого рода.
Кроме того, в большинстве приложений на основе рабочего процесса он входит в качестве программного обеспечения/требования, которое клиент заинтересован в "действиях", выполняемых над рабочим элементом; какие значения были назначены и кто их обработал и т.д.
Я поклонник мягких удалений. В первую очередь для предотвращения каскадных удалений. Однако для этого требуется дополнительный код, поэтому если вы выбрали дочерний объект, он присоединяется к родительским (и всем родительским!) Объектам, чтобы убедиться, что ни один из них не удален. В качестве альтернативы вы можете каскадировать soft-delete, но если вы хотите восстановить их позже, вы можете не знать, какие дети уже были удалены и которые были удалены из-за каскада.
Кроме того, я сохраняю имя даты и времени ревизии для каждого объекта, поэтому я знаю, кто изменил (или мягко удалил) его последний. Затем для контрольного журнала я создаю таблицу * History (например, CustomerHistory), которая вставляется после каждого UPDATE в исходную таблицу. Таким образом, после изменения или мягкого удаления объекта, у меня есть запись о том, кто выполнил действие, а также последнее известное состояние объекта.
Я встречался с мягкими удалениями для следующих широких сценариев:
CASE 1: удалить запись из видимого пользователя/кода, но иметь запись на уровне БД, так как бизнес заинтересован в том, чтобы знать, что у нее есть записи.
Эти требования в основном основаны на бизнесе, и, как правило, в основном это юридическое требование (например, сценарии @joshperry и @armandino), чтобы иметь предыдущую запись в базе данных и создать новую запись для каждого внесенного изменения. На этом этапе я бы посмотрел на CASE 2 и оценил, удовлетворяет ли он требованиям перед тем, как флаг IsDeleted
CASE 2: отслеживать отслеживания эволюции записи - в онлайн-журналах содержится множество приличных статей для ведения журналов аудита записей в базе данных
НТН.