Никогда не удалять записи? Хорошая идея? Обычный?

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

Конечно, им нужно будет удалять записи или, по крайней мере, думать, что они сделали, если они установлены как admin.

Итак, я думал, что все записи в базе данных должны иметь "активное" поле. Если они попытаются удалить запись, она просто установит флаг "false" или что-то подобное. Тогда будет какой-то супер администратор, который будет моей командой компании, которая может изменить это поле.

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

Как вы думаете? Должен ли я так поступать? Используете ли вы этот трюк в своих приложениях?

Ответ 1

В одной из наших баз данных мы различали записи transactional и dictionary.

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

dictionary записи - это вещи, которые вы можете изменить, например, присваивание клиенту city.

transactional записи , и все, что приводит к ним, никогда не удалялось, а dictionary можно было удалить все.

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

Как, a city можно удалить из базы данных. Но когда появилось правило, что "отправить SMS всем клиентам в Москве", города стали также transactional записями, или мы не сможем ответить на вопрос "почему этот SMS отправляется".

Эмпирическое правило для различения было следующим: это только мой бизнес компании?

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

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

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

Но для нашей бизнес-модели правило сверху отлично работало.

Ответ 2

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

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

Ответ 3

Недостатком просто установки флага, такого как IsActive или DeletedDate, является то, что все ваши запросы должны учитывать этот флаг при извлечении данных. Это делает более вероятным, что другой программист случайно забудет этот флаг при написании отчетов...

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

Кроме того, вы можете предоставить функцию отмены, чтобы вернуть ее достаточно быстро; и сделать постоянное удаление через 30 дней или что-то в этом роде.

ОБНОВЛЕНИЕ относительно просмотров:

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

Я предлагаю иметь вторую базу данных, такую как DB_Archives, если вы добавите каждую строку, удаленную из БД. Поле is_active отрицает саму цель ограничений внешнего ключа, и вы должны убедиться, что эта строка не помечена как удаленная, когда она ссылается в другом месте. Это становится чрезмерно сложным, когда структура базы данных массивная.

Ответ 7

Существует приемлемая практика, которая существует во многих приложениях (система управления версиями drupal, et al.). Поскольку MySQL масштабируется очень быстро и легко, вы должны быть в порядке.

Ответ 8

В последнее время я работаю над проектом, где все данные также хранятся в БД. Статус каждой отдельной строки хранился в целочисленном поле (данные могут быть активными, удаленными, in_need_for_manual_correction, историческими).

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

Еще одна вещь, облегчающая работу, заключалась в использовании триггеров UPDATE/INSERT/DELETE, которые обрабатывали весь флаг, изменяющийся внутри БД, и, таким образом, сохраняли сложный материал из приложения (по большей части).

Я должен упомянуть, что БД был сервером MSSQL 2005, но я думаю, что тот же подход должен работать и с mysql.

Ответ 9

Да и нет.

Это усложнит ваше приложение намного больше, чем вы ожидаете, поскольку каждая таблица, которая не позволяет удалять, будет за дополнительной проверкой (IsDeleted = false) и т.д. Это не так много, но тогда, когда вы создаете большее приложение и в запросе 11 в таблицах 9 требуется нечеткое удаление. Это утомительно и подвержено ошибкам. (Ну да, тогда есть удаленные/незаметные представления.. когда вы помните, чтобы делать/использовать их)

Некоторые обновления схем станут PITA, так как вам придется расслабиться FK: s и придумать "подходящие" данные для очень старых данных.

Я не пробовал, но подумал о умеренном количестве решений, где вы бы закрепили данные строки в xml и сохранили их в некоторой "исторической" таблице. Тогда в случае "должно быть, что восстановлено сейчас OMG мир умирает! 1eleven" его можно выкапывать.

Ответ 10

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