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

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

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

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

И наконец, личность играет большую роль. Люди могут быть packrats с данными, также. Если DBA сохраняет все его газеты с 30 лет назад, и не любите удалять данные, возможно, он должен удостовериться, что делает проектные решения данных на основе достоинств и не несоответствующего персонального предпочтения.

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

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

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

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

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

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

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

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

Если Вам иногда будут нужны удаленные данные, но не очень часто: Вы можете перемещать записи в отдельную базу данных / таблица (например, users и users_deleted, или лучше somedb.users и somedb_deleted.users).

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

У Вас должен быть он в функциональных требованиях. Если не сказано там явно, что необходимо будет выяснить его сами.

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

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

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

При использовании удаленного, видимого, isactive, и т.д. столбец, можно абстрагировать далеко необходимость не забыть использовать его при помощи представлений.

Вам решать и Ваши требования (некоторые вещи становятся довольно твердыми, когда записи существуют, которые... не делают).

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

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

Это зависит. (Но Вы предположили, что уже, я уверен.)

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

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

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

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

терминология, которую я обычно использую, "Активна" и "Неактивна".

еще Несколько вопросов для рассмотрения (Totophil):

1. Удаление записи в некоторых базах данных автоматически не освободит дисковое пространство.
2. Чистка любой уязвимой информации, которую Вы больше не запрашиваете, помогает угрозам безопасности предотвращения.

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

   • ЕС http://ec.europa.eu/justice_home/fsj/privacy/law/index_en.htm
   • Великобритания http://www.ico.gov.uk/what_we_cover/data_protection.aspx
   • Эстония http://www.riigiteataja.ee/ert/act.jsp?id=748829

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

Добавление столбца "DELETED" к Вашей таблице и маркировке строк вместо того, чтобы удалить их создает намного больше работы для Вас с мало (если таковые имеются) преимущество. Теперь, каждый раз, когда Вы пишете запрос, необходимо не забыть включать, "ГДЕ УДАЛЕНО NOT NULL" (или безотносительно).

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

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

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

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