База даних: Щоб видалити або не видалити записи

Я не думаю, що я єдина людина, яка цікавиться цим питанням. Що ви зазвичай практикуєте щодо поведінки бази даних? Ви віддаєте перевагу фізично видалити запис із бази даних? Або краще просто позначити запис із "видаленим" прапором або булевим стовпчиком, щоб позначити запис активний чи неактивний?

Це безумовно залежить від фактичного вмісту вашої бази даних. Якщо ви використовуєте його для зберігання інформації про сеанси, то, звичайно, витріть її негайно, коли сеанс закінчується (або закритий), ви не хочете, щоб сміття лежало навколо. Оскільки він справді не може бути використаний знову для будь-яких практичних цілей.

В основному, що потрібно запитати у себе, може мені знадобиться відновити цю інформацію? Як видалені запитання на SO, вони обов'язково повинні бути позначені як "видалені", оскільки ми активно дозволяємо відновлювати. У нас також є можливість відобразити його і для вибраних користувачів, без зайвих робіт.

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

Тимчасові дані див. На веб-сторінці: http://talentedmonkeys.wordpress.com/2010/05/15/temporal-data-in-a-relational-database/

Плюси використання прапора видалення:

1. Ви можете отримати дані пізніше, якщо вони вам потрібні,
2. Операція видалення (оновлення прапора), ймовірно, швидше, ніж дійсно видалення

Мінуси використання прапора видалення:

1. Дуже легко пропустити AND DeletedFlag = 'N'десь у своєму SQL
2. Повільніше базі даних, щоб знайти рядки, які вас цікавлять серед усіх лайнів
3. Зрештою, ви, ймовірно, захочете все-таки видалити його (якщо припустити, що ваша система успішна. А як щодо того, коли цьому запису виповнилося 10 років, і його "видалили" через 4 хвилини після створення)
4. Це може зробити неможливим використання природного ключа. У вас може бути один або кілька видалених рядків із природним ключем та реальним рядком, який бажає використовувати той самий природний ключ.
5. Можливо, існують юридичні причини / відповідність причин, через які ви насправді видаляєте дані.

Як доповнення до всіх публікацій ...

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

Я радий, що знайшов цю тему. Мені теж було цікаво, що люди думають про це питання. Я впроваджував "позначений як видалений" протягом майже 15 років у багатьох системах. Кожного разу, коли користувач закликає сказати, що щось було випадково видалено, це було, безумовно, набагато простіше позначити його видаленим, ніж відтворити його або відновити з резервної копії.

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

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

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

Але, як хтось сказав, іноді вам може знадобитися якийсь конкретний ключ назад з якоїсь причини, в цей момент вам потрібно буде дійсно видалити його, а потім заново створити записи (видалити його та змінити запис).

У будь-якому випадку також є юридичні питання, якщо стосуються персональних даних. Я думаю, що це дуже залежить від того, де ви знаходитесь (чи де знаходиться база даних) та які умови користування.

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

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

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

Якщо ви стурбовані тим, що "спокійні" записи сповільнюють доступ до вашої бази даних, ви можете перенести ці рядки в іншу таблицю, яка виконує роль таблиці "архіву".

Для даних, введених / керованих користувачем, я використовував описаний вами метод прапорця і дав користувачеві інтерфейс "спорожнити сміття", щоб фактично видалити елементи, якщо він захоче.