В совершенно новой программе, где пространство на самом деле не так важно, лучше ли удалить строку или отключить строку, допустив логическое "Отключено" и попросить программу просто игнорировать его?
Например, если я хочу удалить пользователя из программы.
Не удалять создает новый класс ошибок для всех будущих запросов. Не забывайте, что написание запросов часто делают опытные пользователи (т.е. Не ИТ-специалисты) и младшие разработчики. Таким образом, теперь для каждой таблицы, у которой есть недопустимые данные, отмеченные только активным флагом BIT, потребуется дополнительный AND в предложении WHERE для каждого запроса отныне до бесконечности. Это поможет пользователям попасть в яму неудачи вместо успеха. Тем не менее, я настоятельно рекомендую вам реализовать эти системы флагов так или иначе, потому что без плохих дизайнов разработчикам ПО не нужно исправлять многочисленные ошибки, которые он будет создавать.
Насколько ценным является наличие исторических данных в таблице? Если бизнес, если смотреть вперед, имея старые данные в таблицах, может быть просто бременем - это вызывает проблемы при создании ограничений (все ограничения должны быть изменены, чтобы исключить данные, которые вы хотите, не были там). Обеспечение качества данных осложняется необходимостью постоянно переименовывать то, что "старое дерьмо, которого мы боимся удалить, но никогда не хотим когда-либо использовать или обновлять снова" и новые вещи, о которых мы заботимся.
Это удаление, потому что это была ошибка? Если строка соответствует сущности в реальной жизни, возможно, интересно сохранить и установить "испаренный", "мертвый", "оставленный здание". Если вы случайно вставили строку, которая не соответствует ни одному объекту в реальной жизни, DELETE не является плохим. Являются ли воображаемые клиенты, которые никогда не существовали важными для хранения в таблице клиентов?
И, наконец, личность играет большую роль. Люди могут быть packrats с данными, также. Если администратор баз данных хранит все свои газеты с 30 лет назад и не любит удалять данные, возможно, ему следует убедиться, что он принимает решения по разработке данных, основанные на достоинствах, а не на личном предпочтении.
Это зависит. (Но вы уже догадались, что я уже уверен.)
На практике нарушение правильного использования здесь почти всегда в направлении удаления.
Основным плохим следствием удаления является то, как часто есть зависимые записи в других таблицах, ссылочная целостность которых теряется, когда родительская запись уходит.
Одна красная селедка, используемая для защиты удаления (которую вы уже правильно рассмотрели, отклонив проблему емкости хранилища), ожидает, что она сделает заметную разницу в эффективности запросов.
Слишком много случаев, когда проблемы с пользователем или программным обеспечением заставляют кого-то ударить по большой кнопке "Отменить"; если вы удалите, вам не повезло (по крайней мере, не получая особой помощи и отягчающих людей, с которыми вам бы хотелось быть.)
Терминология, которую я обычно использую, - "Активный" и "Неактивный".
Еще несколько пунктов, которые следует учитывать (Totophil):
Законодательство о защите данных может потребовать от вашей организации при определенных обстоятельствах очистить любую идентифицируемую информацию о человеке. Законодательство отличается от страны к стране, некоторые указатели:
С другой стороны, вам может потребоваться по закону хранить определенную информацию.
Прочитав книгу о временном дизайне базы данных, я пришел к мысли, что каждая запись временного значения должна иметь как минимум 4 столбца временной метки. Эти четыре: созданы, удалены, запущены, завершены. Созданные и удаленные временные метки достаточно понятны. Ваша система не должна смотреть на записи, где они были удалены раньше(). Начальный и конечный столбцы определяют, когда данные относятся к вашей системе. Это для сохранения истории изменений. Если вам нужно обновить запись, вы должны установить ее время окончания(), скопировать, обновить копию и установить время начала копирования (теперь). Таким образом, когда вам нужно взглянуть на то, как что-то исторически, вы можете заставить систему понять это. Вы могли бы также установить начало в какой-то момент в будущем, чтобы изменения произошли автоматически в это время, или установите конец в будущем, чтобы оно автоматически исчезло в это время. Установка созданных/удаленных временных меток в будущее на самом деле не имеет смысла...
Если вы используете удаленный, видимый, неактивный и т.д. столбцы, вы можете абстрагироваться от необходимости запоминать его с помощью представлений.
Это зависит от вас и ваших требований (некоторые вещи становятся довольно трудными, когда существуют записи, которые... не работают).
Я скажу, что логическое - это плохой выбор. Сделайте отметку с нулевым значением. Очень удобно знать, когда что-то было удалено, особенно если вы слишком много удалили и хотите отменить часть удаления.
Это зависит. Если он отключен, его легче восстановить или увидеть, что кто-то действительно удалил запись (для аудита).
У вас также может быть техническое требование не удалять записи. Например, если вы хотите синхронизировать свою базу данных с другим пользователем, просто отправив измененные записи, вы не сможете этого сделать, если она была фактически удалена.
Вам нужно иметь его в функциональных требованиях. Если вы не сказали, что вам явно нужно выяснить это самостоятельно.
В большинстве случаев лучше хранить такие записи в отдельной таблице. Затем вы избегаете различных ситуаций, когда одна таблица ссылается на другую таблицу, и вам нужно решить, должны ли записи во второй таблице обрабатываться как удаленные или нет.
Если вам понадобятся удаленные данные иногда, но не очень часто: вы можете переместить записи в отдельную базу данных/table (например, users и users_deleted или лучше somedb.users и somedb_deleted.users).
Таким образом, данные по-прежнему доступны через запрос (хотя это будет не так просто, как обычный), но он не загромождает исходную базу данных, и вам не нужно ее кодировать.
Добавление столбца "DELETED" в вашу таблицу и маркировка строк вместо их удаления создает для вас гораздо больше работы с небольшим (если есть) преимуществом. Теперь, каждый раз, когда вы пишете запрос, вы должны помнить, что включить "WHERE DELETED IS NOT NULL" (или что-то еще).
Лучший подход - удалить данные, когда вам нужно удалить данные, и полагаться на ваш обычный процесс резервного копирования, чтобы гарантировать, что данные не будут потеряны. Если по какой-то причине вам нужно сохранить некоторые удаленные данные удобными (для поиска, возможно), вам лучше просто копировать данные в другую таблицу, созданную для этой цели, а затем удалять оригиналы.
На протяжении многих лет я унаследовал многие базы данных, и эта стратегия заметок записей вместо их удаления, к сожалению, очень распространена, и (по моему опыту, по крайней мере) всегда приводит к серьезным проблемам в будущем.
Если вам не нужна конкретная потребность в управлении своими собственными удалениями, вам лучше просто удалить строки.
Я хотел бы отметить, что в большинстве стран используются прецеденты, в которых вы не можете удалять записи по юридическим причинам. Конечно, промышленность и данные зависят.
В этом случае я считаю, что наилучшей практикой является теневая таблица "удаленных" данных, которая наделяет вас преимуществами фактического удаления изложенным MatthewMartin и по расширению я пришли к выводу, что этот шаблон часто предпочтительнее создания "активных" бит-флагов в моих таблицах данных.
Это должно определяться потребностями приложения. Я сделал это в обоих направлениях. У меня есть некоторые приложения, которые должны поддерживать отмену, поскольку стоимость удаления строки - и каскадные удаления, вызванные этим, - слишком дороги, чтобы их не было. Обычно, однако, приложения, которые я сделал, требуют, чтобы пользователь подтвердил удаление, а затем просто сделайте так, как пользователь спросил. В некоторых случаях вы должны удалить данные из-за проблем с конфиденциальностью. То есть, если пользователь просит удалить его, вам действительно нужно удалить его, а не просто пометить его как неактивным. В других случаях (например, в отношении сделок, связанных с налогами) могут быть причины хранить данные в несрочном состоянии до тех пор, пока это не будет требоваться законом. У меня есть приложения, которые подходят для обеих категорий.
В случае, когда вам нужно хранить "архивные" данные, можно использовать различные стратегии. В зависимости от того, должен ли он быть немедленно доступен, вы можете нажать на него, чтобы архивировать таблицы, которые либо сохраняются, либо сохраняются и регулярно очищаются. Если есть необходимость в отмене, вы можете сохранить его в текущей таблице и просто пометить его, установив флаг. Это в значительной степени зависит от сложности вашей схемы, требований приложения и личных предпочтений.
Это вызов для решения, но я добавил, что добавленные столбцы "отключены" в таблицах, где раньше я думал, что могу просто удалить строку. Я бы сказал, что большую часть времени вы безопаснее добавляете отключенный столбец. Это может оказаться сложным с n: n отношениями, поэтому, чтобы что-то рассмотреть.
Вероятно, лучше всего добавить "удаленный" столбец и предложить пользователям восстановить или удалить удаленные элементы.
Это зависит от функции базы данных. Это источник всей правды? Если да, то отключите, а не удаляйте, так как легче восстановить из-за плохих операций (например, ошибки пользователя). Если база данных подается из какого-либо источника данных вверх, удалите неиспользуемые данные. Любое воссоздание/восстановление может быть выполнено с помощью восходящей системы.
Как уже говорилось, приложение требует диктовать то, что вы хотите сделать. Но для меня разметка строки кажется неправильной для правильного инструмента. Мы логически думаем об удалении как DELETE, поэтому, если вам не разрешено удалять по юридическим причинам, вы не удаляете его в первую очередь. В то же время, я думаю о сохранении и индексировании внутренней структуры данных. Не говоря уже обо всех оптимизации, которые могут быть сделаны для извлечения данных, но добавление этой проверки (в представлении или в запросе) влияет на производительность по экспоненте со сложностью базы данных и отношениями, которые имеют сущности.
Вкратце, поместите логику удаления на уровне пользовательского интерфейса, чтобы предотвратить ошибки пользователя и предоставить разрешения на удаление для пользователей, которые должны иметь возможность удалить их. Используйте регулярные резервные копии для хранения архивов. Если ваше приложение абсолютно требует строгой истории аудита, внедряйте его в триггеры и ставьте аудит в базу данных вне сайта, чтобы избежать всего этого трафика, проверки и дерьма из производства.
Для этого есть два дополнительных решения, которые я обычно использовал. Я согласен с другими людьми, которые опубликовали, что это действительно зависит от ваших данных.
Вы можете запретить пользователю удалять запись, если это вызовет проблемы ссылочной целостности, используя ограничения внешнего ключа (если ваша RDBMS поддерживает это). Несколько раз я предоставлял конечному пользователю сообщение о том, что "вы не можете удалить этот < объект > до тех пор, пока вы не отсоедините его < parent object > ". Это может работать до тех пор, пока вы не ожидаете, что существует огромное количество ассоциаций с другой таблицей или таблицей.
Другой подход заключается в перемещении любых дизассемблированных записей, связанных с записью, которая не удаляется. Например, скажем, у вас есть курс, для которого с ним связаны 10 отдельных классов. Если вы удалите курс, вы можете разрешить пользователю решить, удалены ли все 10 классов или связаны с новым или существующим курсом.
Я создаю CRUD и сталкиваюсь с той же проблемой.
Решение: D из CRUD следует отключить вместо удаления.
Проблемы:
Большая проблема