База данных: удалить или не удалить записи

Профессионалы использования удалить флага:

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

Недостатки использования удалить флага:

1. очень легко отсутствовать AND DeletedFlag = 'N' где-нибудь в Вашем SQL
2. Медленнее для базы данных для нахождения строк, что Вы интересуетесь среди всего дерьма
3. В конечном счете, Вы, вероятно, захотите действительно удалить его так или иначе (предполагающий, что Ваша система успешна. Что относительно того, когда той записи 10 лет, и она была "удалена" спустя 4 минуты, после того, как первоначально создано)
4. , Она может лишить возможности использовать естественный ключ. У Вас может быть одна или несколько удаленных строк с естественным ключом и реальная строка, желающая использовать тот же самый естественный ключ.
5. могут быть легальные причины / причины соответствия, почему Вы предназначены для фактического удаления данных.

Как дополнение ко всем сообщениям...

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

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

Мы используем postgresql и Ruby на направляющих, похоже, что мы могли сделать это 1 из двух способов, изменить направляющие или добавить, что ondelete инициировал, и делает вместо этого функцию pl/pgsql для маркировки, как удалено. Я склоняюсь к последнему.

Что касается хитов производительности, будет интересно видеть, что результаты ОБЪЯСНЯЮТ - АНАЛИЗИРУЮТ на больших таблицах к немногим удаленным объектам, а также многим удаленным объектам.

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

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

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

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

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

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

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

Для user-entered/managed данных я использовал метод флага, который Вы описываете и, учитывая пользователя "пустой мусор" интерфейс для фактического удаления объектов, если они принимают решение.