База данных: удалять или не удалять записи - PullRequest
105 голосов
/ 02 февраля 2009

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

Ответы [ 8 ]

45 голосов
/ 02 февраля 2009

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

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

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

Временные данные см .: http://talentedmonkeys.wordpress.com/2010/05/15/temporal-data-in-a-relational-database/

25 голосов
/ 02 февраля 2009

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

  1. Вы можете получить данные позже, если вам это нужно,
  2. Операция удаления (обновление флага), вероятно, выполняется быстрее, чем ее удаление

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

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

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

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

10 голосов
/ 17 февраля 2009

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

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

Что касается производительности, будет интересно увидеть результаты EXPLAIN-ANALYZE для больших таблиц для нескольких удаленных элементов, а также для многих удаленных элементов.

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

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

6 голосов
/ 02 февраля 2009

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

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

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

5 голосов
/ 02 февраля 2009

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

2 голосов
/ 02 февраля 2009

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

1 голос
/ 02 февраля 2009

Для введенных пользователем / управляемых данных я использовал описанный вами метод флага и дал пользователю интерфейс «очистить корзину» для фактического удаления элементов, если они захотят.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...