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

При работе над проектом в данный момент и мы должны реализовать мягкое удаление для большинства пользователей (пользовательские роли). Мы решили добавить is_deleted='0' поле на каждой таблице в базе данных и наборе это к '1' если конкретный пользовательский ролевой хит удалить кнопка на определенной записи.

Для будущего обслуживания теперь, каждого SELECT запрос должен будет гарантировать, чтобы они не включали записи where is_deleted='1'.

Существует ли лучшее решение для реализации мягкого удаления?

Обновление: Я должен также отметить, что у нас есть База данных аудита, которая отслеживает изменения (поле, старое значение, новое значение, время, пользователь, IP) ко всем таблицам/полям в базе данных Application.

44
задан MarredCheese 8 September 2019 в 22:34
поделиться

11 ответов

Вы могли выполнить все свои запросы против представления, которое содержит WHERE IS_DELETED='0' пункт.

47
ответ дан David J. Sokol 26 November 2019 в 21:36
поделиться

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

и индексировать is_deleted столбец для больших таблиц

, так как у Вас уже есть журнал аудита, отслеживание даты удаления избыточно

0
ответ дан MarredCheese 26 November 2019 в 21:36
поделиться

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

0
ответ дан UnkwnTech 26 November 2019 в 21:36
поделиться

Вы не упоминаете, какой продукт, но SQL Server 2008 и postgresql (и другие я уверен) позволяют Вам создавать фильтрованные индексы, таким образом, Вы могли создать закрывающий индекс где is_deleted=0, смягчив некоторые отрицательные стороны этого конкретного подхода.

2
ответ дан Andy Irving 26 November 2019 в 21:36
поделиться

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

Добавление where deleted=0 ко всем Вашим запросам значительно замедлит их и препятствует использованию любого из индексов, которые Вы можете иметь на таблице. Постарайтесь не иметь "флаги" в своих таблицах, когда это возможно.

4
ответ дан Brent 26 November 2019 в 21:36
поделиться

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

Масштабы хорошо и информационно-центрическое хранение довольно маленького места данных - ключ для 350 ГБ + dbs с проблемами в реальном времени. Используя альтернативы, таблицы, триггеры имеют немного служебные, который в зависимости от потребности может или не может работать на Вас.

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

1
ответ дан 26 November 2019 в 21:36
поделиться

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

Делают Вы хотите быть в состоянии к:

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

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

10
ответ дан Daniel Fortunov 26 November 2019 в 21:36
поделиться

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

В SQL Server, лучшее решение состояло бы в том, чтобы использовать deleted_on/deleted_at столбец с типом SMALLDATETIME или ДАТЫ И ВРЕМЕНИ (в зависимости от необходимой гранулярности) и сделать тот столбец nullable. В SQL Server данные заголовка строки содержат ПУСТУЮ битовую маску для каждого из столбцов в таблице, таким образом, это незначительно быстрее для выполнения, ЯВЛЯЕТСЯ ПУСТЫМ или NOT NULL, чем это должно проверить значение, сохраненное в столбец.

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

я обычно избегаю полей признака как is_deleted, is_archive, и т.д. потому что они только несут одну часть значения. nullable deleted_at, archived_at поле обеспечивает дополнительный уровень значения себе и тому, кто бы ни наследовал Ваше приложение. И я избегаю полей битовой маски как чумы, так как они требуют понимания того, как битовая маска была создана для схватывания любого значения.

14
ответ дан Jeremiah Peschka 26 November 2019 в 21:36
поделиться

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

тот способ, которым Вы не должны добавлять другой столбец к своей первичной таблице

13
ответ дан Jiaaro 26 November 2019 в 21:36
поделиться

Столбец Having is_deleted является довольно хорошим подходом. Если бы это находится в Oracle, для дальнейшего увеличения производительности я рекомендовал бы делить таблицу путем создания раздела списка на is_deleted столбец. Тогда удаленные и неудаленные строки физически будут в различных разделах, хотя для Вас это будет прозрачно.

В результате при вводе запроса как

SELECT * FROM table_name WHERE is_deleted = 1

тогда Oracle выполнит 'сокращение раздела' и только изучит соответствующий раздел. Внутренне раздел является различной таблицей, но это прозрачно для Вас как пользователь: Вы будете в состоянии выбрать через всю таблицу, неважно, если она будет разделена или нет. Но Oracle будет в состоянии запросить ТОЛЬКО раздел, в котором она нуждается . Например, давайте предположим, что у Вас есть 1 000 строк с is_deleted = 0 и 100 000 строк с is_deleted = 1, и Вы делите таблицу на is_deleted. Теперь при включении условия

WHERE ... AND IS_DELETED=0

тогда, Oracle ТОЛЬКО просканирует раздел с 1 000 строк. Если бы таблица не была разделена, она должна была бы просканировать 101 000 строк (оба раздела).

20
ответ дан Izzy Ahmad 26 November 2019 в 21:36
поделиться

Я склонился бы к "Направляющим путь" с deleted_at столбец, который содержит дата и время того, когда удаление произошло . Тогда Вы получаете определенные свободные метаданные об удалении. Для Вашего SELECT просто получают строки WHERE deleted_at IS NULL

86
ответ дан ctcherry 26 November 2019 в 21:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: