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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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