Чи слід коли-небудь видаляти дані в базі даних?

Я новачок у базах даних і намагаюся зрозуміти основні поняття. Я навчився видаляти дані в базі даних. Але один з моїх друзів сказав мені, що ніколи не слід видаляти дані в базі даних. Швидше, коли його більше не потрібно, краще просто позначити його або позначити як "не використовується".

Це правда? Якщо так, то як велика компанія, як 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", наприклад, виберіть blah з таблиці1, де date_time_removed недійсний

Звичайно, рядки, які випадково були додані до бази даних, слід видаляти назавжди, особливо тестові дані.

Зберігаючи всі законні дані, ви також маєте можливість використовувати вашу базу даних для зберігання в майбутньому.

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

Зберігання архівів видалених даних не було б такою великою справою. Великі компанії також можуть зберігати версії коду та багато іншої інформації (не кажучи про нетехнічні пов'язані речі), тому врешті-решт зберігання великих даних є для них чимось звичним.