Должен ли я удалить или отключить строку в реляционной базе данных?

Question

В совершенно новой программе, где пространство не так уж важно, лучше удалить строку или отключить строку, скажем, логическим значением «Отключено», и программа просто игнорирует его?

Например, если я хочу удалить пользователя из программы.

Answer 1

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Вы можете запретить пользователю удалять записи, если это вызовет проблемы ссылочной целостности, используя ограничения внешнего ключа (при условии, что ваша СУБД поддерживает это). Несколько раз я предоставлял конечному пользователю сообщение: «Вы не можете удалить этот , пока не отсоедините <родительский объект> с ним». Это может работать до тех пор, пока вы не предвидите, что существует огромное количество ассоциаций с другой другой таблицей или таблицами.

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

Answer 7

Я создаю CRUD и сталкиваюсь с той же проблемой.

Решение: D из CRUD следует отключить вместо удаления.

Проблемы:

• «Каждый» запрос должен проверять, отключен ли реестр или нет (например, flag = 1). Более конкретно, когда-либо выберите * следует проверить это.
• Каждая вставка должна активировать реестр (флаг = 1) по умолчанию.
• Обновление не должно менять флаг.
• Disable - скрытое обновление, помечающее флаг = 0.

Большая проблема

• Сборщик мусора. Существует три стратегии: удалить старые реестры, удалить реестры, на которые нет ссылок, или сочетание стратегий.

Answer 8

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