Должен ли я удалить или отключить строку в реляционной базе данных? - PullRequest
27 голосов
/ 07 декабря 2008

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

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

Ответы [ 18 ]

22 голосов
/ 07 декабря 2008

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

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

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

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

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

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


Еще несколько моментов, которые нужно рассмотреть (Totophil):

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

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

22 голосов
/ 07 декабря 2008

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

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

Это было удалено, потому что это была ошибка? Если строка соответствует сущности в реальной жизни, может быть, интересно сохранить и установить флаг «испарился», «мертв», «покинул здание». Если вы случайно вставили строку, которая не соответствует сущности в реальной жизни, УДАЛИТЬ не является плохой вещью. Разве воображаемые клиенты, которых никогда не было, важно держать в таблице клиентов?

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

17 голосов
/ 07 декабря 2008

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

16 голосов
/ 07 декабря 2008

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

6 голосов
/ 07 декабря 2008

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

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

4 голосов
/ 08 декабря 2008

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

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

4 голосов
/ 07 декабря 2008

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

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

4 голосов
/ 07 декабря 2008

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

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

3 голосов
/ 07 декабря 2008

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

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

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

2 голосов
/ 08 декабря 2008

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

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

...