Должны ли мы когда-либо удалять данные в базе данных?

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

Это правда? Если да, то как крупная компания, такая как IBM, будет обрабатывать свои данные в течение ста и более лет?

Как и во всех этих вещах, ответ «это зависит».

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

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

Однако, если данные эфемерны или легко восстанавливаются, вы можете решить действительно удалить данные.

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

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

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

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

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

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

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

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

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

Что еще хуже, что произойдет, если вы удалите принтер 13 и перетасуете все принтеры, которые идут за ним, чтобы заполнить пробел? Принтер 14 (некоторая дряхлая старая точечная матрица) становится принтером 13, принтер 15 становится принтером 14 и так далее.

На всех принтерах есть ярлыки, так что они могут иметь перекрестные ссылки с базой данных, но теперь все ярлыки устарели. Вам придется обойти, найти каждый принтер в бизнесе (который может исчисляться сотнями!) И перемаркировать их. Это вряд ли эффективное использование времени. И это также подверженный ошибкам процесс, и что произойдет, если это просто никогда не будет сделано? Кто-то звонит, чтобы сказать, что принтер 14 вышел из строя и нуждается в срочном ремонте, так что вы посмотрите на него и обнаружите, что принтер 14 - это струйный принтер в приемной. Только потому, что вы перетасовали идентификаторы, на самом деле точечный матричный принтер нуждается в срочном ремонте. Парня, который вызвал проблему, оставляют в покое, в то время как у администратора есть парень технической поддержки, которого она никогда не вызывала, чтобы починить принтер, который не сломался.

Вы должны думать об идентификаторах, назначенных системой автоинкремента, как о постоянных, они неизменны и не могут быть повторно использованы, даже если вещь, на которую ссылается идентификатор, перестает существовать. Некоторые люди утверждают, что им не нужно беспокоиться об исчерпании идентификаторов, но даже с 32-разрядными системами и подписанными идентификаторами все еще доступно около 2 миллиардов идентификаторов. Если вы можете сделать столбец идентификаторов без знака, то это удвоится до 4 миллиардов, и в 64-разрядных системах число доступных идентификаторов буквально больше, чем количество звезд на небе. Вы не собираетесь исчерпать удостоверения личности.

Здесь уже много хороших ответов. Я просто хочу добавить одну ситуацию, о которой еще никто не упоминал:

Чувствительные данные . Если пользователь удаляет его, лучше удалить его!

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

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

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

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

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

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

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

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

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

Вы должны добавить столбцы «Date_Time_Removed» в каждую таблицу, а затем вместо физического удаления строк, вы устанавливаете дату и время, когда строка была фактически удалена. Затем в ваших хранимых процедурах или sql вы бы включили столбец «Date_Time_Removed», например, выберите бла из таблицы 1, где date_time_removed равно нулю

Конечно, строки, которые были случайно добавлены в базу данных, должны быть удалены навсегда, особенно тестовые данные.

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

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

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