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

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

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

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

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

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

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

ОБНОВЛЕНИЕ, касающееся видов:

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

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

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

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

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

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

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

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

Да и нет.

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

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

Я не пробовал, но немного подумал о решении, где бы вы заархивировали данные строки в xml и сохранили их в некоторой «исторической» таблице. Тогда, в случае, если «восстановил сейчас ОМГ, мир умирает!

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

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