Фізичне та логічне / м'яке видалення запису бази даних?

Яка перевага робити логічне / м'яке видалення запису (тобто встановити прапор, який стверджує, що запис видалено) на відміну від фактичного або фізичного видалення запису?

Це звичайна практика?

Це безпечно?

Переваги полягають у тому, що ви зберігаєте історію (добре для аудиту) і вам не потрібно турбуватися про каскадування видалення за допомогою інших інших таблиць у базі даних, які посилаються на рядок, який ви видаляєте. Недоліком є ​​те, що вам потрібно кодувати будь-які методи звітування / відображення, щоб врахувати прапор.

Що стосується звичайної практики - я б сказав так, але як ні в чому, чи використовуєте ви це, залежить від ваших потреб бізнесу.

EDIT: Думка про інший недолік - Якщо у вас є унікальні індекси на столі, видалені записи все ще будуть приймати запис "one", тому вам доведеться також кодувати цю можливість (наприклад, таблиця User, яка має унікальний індекс на ім'я користувача; видалена запис все ще блокує ім’я користувача для видалених користувачів для нових записів. Працюючи навколо цього, ви можете привласнити GUID до стовпця видаленого імені користувача, але це дуже хиткий спосіб вирішення, який я б не рекомендував. Можливо, у цій обставині це буде краще мати лише правило, що після використання імені користувача його ніколи не можна замінити.)

Чи логічно видаляється звичайна практика? Так, я бачив це в багатьох місцях. Вони безпечні? Це насправді залежить, чи вони менш безпечні, ніж дані, перш ніж ви їх видаляли?

Коли я був технічним керівником, я вимагав від нашої команди зберігати кожен фрагмент даних, я тоді знав, що ми будемо використовувати всі ці дані для створення різних програм BI, хоча тоді ми не знали, які вимоги будуть бути. Хоча це було добре з точки зору аудиту, усунення несправностей та звітності (Це був сайт електронної комерції / інструментів для транзакцій B2B, і якщо хтось використовував інструмент, ми хотіли записати його, навіть якщо згодом його обліковий запис було вимкнено), у нього було кілька недоліків.

До недоліків можна віднести (не враховуючи інших згаданих):

1. Продуктивність Наслідки збереження всіх цих даних. Ми розробляємо різні стратегії архівування. Наприклад, одна область програми наближалася до генерування близько 1 Гб даних на тиждень.
2. Витрати на зберігання даних з часом зростають, тоді як дисковий простір коштує дешево, кількість інфраструктури для зберігання та керування терабайтними даними як в Інтернеті, так і в режимі офлайн - дуже багато. Для резервування потрібно багато диска, і час людей для забезпечення резервного копіювання швидко рухається тощо.

Вирішуючи використовувати логічні, фізичні видалення або архівування, я задаю собі такі запитання:

1. Це дані, які, можливо, потрібно буде знову вставити в таблицю. Наприклад, облікові записи користувачів підходять до цієї категорії, оскільки ви можете активувати або деактивувати обліковий запис користувача. У такому випадку логічне видалення має найбільше значення.
2. Чи є якесь властиве значення для зберігання даних? Якщо так, то скільки даних буде створено. Залежно від цього я б або перейшов з логічним видаленням, або реалізував стратегію архівації. Майте на увазі, що ви завжди можете архівувати логічно видалені записи.

Це може бути трохи пізно, але я пропоную всім перевірити публікацію в блозі Pinal Dave про логічне / м'яке видалення:

Мені просто не подобається такий дизайн [soft delete]. Я твердо вірю в архітектуру, де в одній таблиці повинні бути лише необхідні дані, а непотрібні дані повинні бути переміщені до архівованої таблиці. Замість того, щоб дотримуватися стовпця isDeleted, я пропоную використовувати дві різні таблиці: одну із замовленнями та другу із видаленими замовленнями. У такому випадку вам доведеться підтримувати обидві таблиці, але насправді це дуже просто. Коли ви пишете оператор UPDATE у стовпчик isDeleted, запишіть INSERT INTO в іншу таблицю і видаліть її з оригінальної таблиці. Якщо ситуація відхилена, напишіть іншу INSERT INTO та DELETE у зворотному порядку. Якщо ви стурбовані невдалою транзакцією, введіть цей код у TRANSACTION.

Які переваги меншої таблиці віршів більшої таблиці у вищеописаних ситуаціях?

• Менший стіл легко обслуговувати
• Операції відновлення індексу набагато швидше
• Переміщення даних архіву в іншу файлову групу призведе до зменшення завантаження первинної групи файлів (враховуючи, що всі групи файлів в іншій системі) - це також прискорить резервне копіювання.
• Статистика буде часто оновлюватися через менший розмір, і це буде менш ресурсомістким.
• Розмір індексу буде меншим
• Продуктивність таблиці покращиться при меншому розмірі столу.

Я розробник NoSQL, і на останньому своєму роботі я працював з даними, які завжди були важливими для когось, і якщо вони були видалені випадково в той самий день, коли було створено, я не зміг його знайти в останній резервній копії з учорашнього дня! У цій ситуації м'яке видалення завжди рятувало день.

Я робив м'яке видалення за допомогою часових позначок, реєструючи дату видалення документа:

IsDeleted = 20150310  //yyyyMMdd

Щонеділі по базі даних ходив процес і перевіряв IsDeletedполе. Якщо різниця між поточною датою та часовою позначкою перевищувала N днів, документ було видалено жорстко. Враховуючи, що документ все ще доступний на деякій резервній копії, це було безпечно зробити.

EDIT: Цей випадок використання NoSQL - це великі документи, створені в базі даних, десятки чи сотні їх щодня, але не тисячі чи мільйони. Загалом це були документи зі статусом, даними та вкладеннями процесів робочого процесу. Це було причиною того, що користувач мав можливість видалити важливий документ. Користувачем може бути хтось із правами адміністратора, або, можливо, власник документа, щоб назвати лише декілька.

TL; DR Моє використання не було великими даними. У такому випадку вам знадобиться інший підхід.

Я використовував один шаблон - створити дзеркальну таблицю та приєднати тригер до первинної таблиці, тому всі видалення (та оновлення, якщо потрібно) записуються в дзеркальну таблицю.

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

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

Ще одна перевага полягає в тому, що дзеркальну таблицю можна самостійно прочистити, оскільки вона не повинна мати жодних фактичних посилань на зовнішні ключі, що робить це порівняно простою операцією порівняно з очищенням з первинної таблиці, яка використовує м'які делети, але все ще має референтні зв’язки з іншими таблицями.

Які ще переваги? - чудово, якщо у вас є купа кодерів, що працюють над проектом, ви читаєте базу даних зі змішаною майстерністю та увагою до рівнів деталей, вам не доведеться спати ночами, сподіваючись, що один із них не забув не включити видалені записи (lol, не включають видалені записи = правда), що призводить до таких речей, як завищення: кажуть, що клієнти мають доступну готівкову позицію, з якою вони потім купують деякі акції (наприклад, як у торговій системі), коли ви працюєте з торговими системами, ви дуже швидко з’ясують значення надійних рішень, навіть якщо вони можуть мати трохи більше початкових «накладних витрат».

Винятки:
- в якості посібника використовуйте м'які делети для "посилань" даних, таких як користувач, категорія тощо, і жорсткі видалення до дзеркальної таблиці для даних типу "факт", тобто історії транзакцій.

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

Це добре працює, оскільки у вас все ще є дані, якщо ви коли-небудь проходили аудит. Якщо ви видалите його фізично, він пропаде !

Я великий прихильник логічного видалення, особливо для додатків Line Business або в контексті облікових записів користувачів. Мої причини прості: часто я не хочу, щоб користувач більше не міг користуватися системою (тому обліковий запис позначається як видалений), але якщо ми видалили користувача, ми втратимо всю його роботу та інше.

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

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

Я майже завжди м'яко видаляю, і ось чому:

• ви можете відновити видалені дані, якщо клієнт попросить вас це зробити. Більше щасливих клієнтів з м'якими делетами. Відновлення конкретних даних із резервного копіювання є складним
• перевірка на isdeletedвсюди не є проблемою, ви useridвсе одно повинні перевірити (якщо база даних містить дані багатьох користувачів). Ви можете застосувати перевірку за кодом, поставивши ці дві перевірки на окрему функцію (або використовуючи представлення даних)
• витончене видалення. Користувачі або процеси, які працюють із видаленим вмістом, продовжуватимуть "бачити" його до наступного оновлення. Це дуже бажана функція, якщо процес обробляє деякі дані, які раптово видаляються
• синхронізація: якщо вам потрібно розробити механізм синхронізації між базою даних та мобільними додатками, ви знайдете м'які видалення набагато простіше в реалізації

Re: "Це безпечно?" - це залежить від того, що ви маєте на увазі.

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

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

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

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

Перш за все, кожен запит повинен піклуватися про поле IsDeleted, а можливість помилок стає вищою при складних запитах.

По-друге, вистава: уявіть собі таблицю з 100000 записів з лише 3 активними, а тепер помножте це число на таблиці вашої бази даних; Ще одна проблема продуктивності - можливий конфлікт із новими записами зі старими (видаленими записами).

Єдиною перевагою, яку я бачу, є історія записів, але є інші методи для досягнення цього результату, наприклад, ви можете створити таблицю журналів, де можна зберегти інформацію: TableName,OldValues,NewValues,Date,User,[..]де *Valuesможна знаходитись varcharі записувати деталі в цю форму fieldname : value; [..] або зберігати інформацію як xml.

Все це можна досягти за допомогою коду або тригерів, але ви - лише ОДНА таблиця з усією історією. Інший варіант полягає в тому, щоб побачити, чи вказаний двигун бази даних є вбудованою підтримкою для відстеження змін, наприклад, у базі даних SQL Server є зміни даних SQL Track.

Я раніше робив м'яке видалення, просто для того, щоб зберігати старі записи. Я зрозумів, що користувачі не намагаються переглядати старі записи так часто, як я думав. Якщо користувачі хочуть переглядати старі записи, вони можуть просто переглядати з таблиці архівів чи аудиту, правда? Отже, яка перевага програмного видалення? Це призводить лише до більш складних операторів запиту тощо.

Нижче описані речі, які я реалізував, перш ніж я вирішив більше не м'яко видаляти:

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

2. визначте, які таблиці вважаються "транзакційною таблицею", що дуже ймовірно, що вона буде зберігатися довгий час, і дуже ймовірно, що користувач може захотіти переглянути минулі записи чи звіти. Наприклад; угода про купівлю. Ця таблиця повинна не тільки зберігати ідентифікатор головної таблиці (наприклад, dept-id), але й зберігати додаткову інформацію, таку як ім'я як посилання (наприклад, назва dept) або будь-які інші необхідні поля для звітування.

3. Реалізуйте "активний / неактивний" або "включити / відключити" або "приховати / показати" запис головної таблиці. Отже, замість видалення запису користувач може відключити / неактивувати основний запис. Це набагато безпечніше.

Тільки мої два центи думка.

Логічні вилучення, якщо важкі для референтної цілісності.

Це правильно вважати, коли є часовий аспект даних таблиці (дійсні FROM_DATE - TO_DATE).

В іншому випадку перемістіть дані до таблиці аудиту та видаліть запис.

З плюсу:

Це простіший спосіб відкату (якщо це взагалі можливо).

Неважко зрозуміти, якою була держава в конкретний момент часу.

Це досить стандартно у випадках, коли ви хочете зберегти історію чогось (наприклад, облікові записи користувачів, як згадує @Jon Dewees). І це, звичайно, прекрасна ідея, якщо є великий шанс користувачів запитати про видалення.

Якщо ви стурбовані логікою відфільтрування видалених записів із запитів, які стають безладними та просто ускладнюють ваші запити, ви можете просто створити представлення, які фільтрують для вас, і використовувати запити проти цього. Це запобігає витоку цих записів у рішеннях звітності тощо.

Існують вимоги, що не відповідають проектуванню системи, на які потрібно відповісти. Яка юридична чи законодавча вимога щодо зберігання записів? Залежно від того, з чим пов’язані рядки, може бути юридична вимога зберігати дані протягом певного періоду часу після їх "призупинення".

З іншого боку, вимога може полягати в тому, що після того, як запис буде видалено, він буде справді і безповоротно видалений. Перш ніж приймати рішення, поговоріть зі своїми зацікавленими сторонами.

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

Вони не дозволяють базі даних працювати так, як це повинно робити такі речі, як функціонал каскаду, марними.

Для простих речей, таких як вставки, у випадку повторної вставки код за ним подвоюється.

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

Вони викликають проблеми з продуктивністю, оскільки таблиці забиваються зайвими даними. Це грає на хаос з індексацією, особливо з унікальністю.

Я не великий фанат логічних делетів.

Щоб відповісти на коментар Тохід, ми зіткнулися з тією ж проблемою, коли ми хотіли зберегти історію записів, а також не були впевнені, хочемо ми is_deletedстовпець чи ні.

Я говорю про нашу реалізацію python та подібний випадок використання, який ми вражаємо.

Ми зіткнулися з https://github.com/kvesteri/sqlalchemy-continuum, що є простим способом отримати таблицю версій для відповідної таблиці. Мінімальні рядки коду та історія захоплення для додавання, видалення та оновлення.

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

Таким чином, нам взагалі не потрібно було мати is_deletedстовпчик, і наша функція видалення була досить тривіальною. Таким чином, нам також не потрібно пам’ятати, щоб відзначати is_deleted=Falseв будь-якому з наших api.

Soft Delete - це програма програмування, яку дотримуються в більшості додатків, коли дані є більш релевантними. Розглянемо випадок фінансового застосування, коли видалення помилкою кінцевого користувача може бути фатальним. Це той випадок, коли м'яке видалення стає актуальним. У режимі м'якого видалення користувач фактично не видаляє дані з запису, а замість того, що вони позначені як IsDeleted в true (За звичайним умовою).

У EF 6.x або EF 7 далі Softdelete додається як атрибут, але зараз ми повинні створити спеціальний атрибут.

Я настійно рекомендую SoftDelete в дизайні бази даних та її хорошій умові для практики програмування.

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

Насправді це більше схоже на переформулювання видимої / прихованої або активної / неактивної функції. Тому що це сенс "видалити" в світі бізнесу. Я хотів би сказати, що Термінатори можуть видаляти людей, але бос їх просто звільняє.

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

З точки зору безпеки, SoftDelete не замінить роботу аудиту, а також не замінить роботу резервного копіювання. Якщо ви боїтесь "вставити / видалити між двома резервними копіями", слід ознайомитись з моделями повного або масового відновлення. Я визнаю, що SoftDelete може зробити процес відновлення більш тривіальним.

Ви повинні знати свою вимогу.

Щоб запропонувати альтернативу, у нас є користувачі, які використовують віддалені пристрої, що оновлюються через MobiLink. Якщо ми видаляємо записи в базі даних серверів, ці записи ніколи не будуть позначені видаленими в клієнтських базах даних.

Так ми робимо і те, і інше. Ми працюємо з нашими клієнтами, щоб визначити, як довго вони бажають мати можливість відновити дані. Наприклад, зазвичай клієнти та продукти активні, поки наш клієнт не скаже, що їх слід видалити, але історія продажів зберігається лише 13 місяців, а потім автоматично видаляється. Клієнт може захотіти зберігати видалених клієнтів і продукти протягом двох місяців, але зберігати історію протягом шести місяців.

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

Ми менше стосуємося безпеки даних, ніж про наявність величезних баз даних на клієнтському пристрої з обмеженою пам’яттю, наприклад смартфоні. Клієнт, який замовляє 200 товарів двічі на тиждень протягом чотирьох років, матиме понад 81 000 рядків історії, з яких 75% клієнту не байдуже, чи бачить він.

Все залежить від випадку використання системи та її даних.

Наприклад, якщо ви говорите про урядову систему, що регулюється (наприклад, система фармацевтичної компанії, яка вважається частиною системи якості і повинна дотримуватися вказівок FDA щодо електронних записів), то вам не пощастило краще не робити жорстких видалень! Аудитор з FDA може зайти і попросити всі записи в системі, що стосуються номера продукту ABC-123, і всі дані краще матимуть доступні. Якщо власник вашого бізнес-процесу каже, що система не повинна дозволяти нікому використовувати номер продукту ABC-123 для нових записів, що рухаються вперед, скористайтеся методом програмного видалення, щоб зробити його "неактивним" в системі, зберігаючи історичні дані.

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

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

Ну! Як усі казали, це залежить від ситуації.

Якщо у вас є індекс у стовпці, наприклад UserName або EmailID, і ви ніколи не очікуєте, що те саме UserName або EmailID буде використане знову; ви можете перейти з м'яким видаленням.

З цього приводу завжди перевіряйте, чи використовується ваша операція SELECT первинного ключа. Якщо ваш оператор SELECT використовує первинний ключ, додавання прапора із пунктом WHERE не має великої різниці. Візьмемо приклад (псевдо):

Користувачі таблиці (UserID [первинний ключ], EmailID, IsDeleted)

SELECT * FROM Users where UserID = 123456 and IsDeleted = 0

Цей запит не матиме жодних змін у відношенні продуктивності, оскільки стовпець UserID має первинний ключ. Спочатку він сканує таблицю на основі ПК, а потім виконає наступну умову.

Випадки, коли м'які видалення взагалі не можуть працювати:

Реєстрація на всіх веб-сайтах приймає EmailID як вашу унікальну ідентифікацію. Ми дуже добре знаємо, щоразу, коли EmailID використовується на веб-сайті, як facebook, G +, його ніхто не може використовувати.

Настає день, коли користувач хоче видалити свій профіль з веб-сайту. Тепер, якщо ви зробите логічне видалення, цей користувач більше не зможе зареєструватися. Крім того, повторна реєстрація за допомогою того ж EmailID не означатиме відновлення всієї історії. Всім відомо, вилучення означає видалення. У таких сценаріях нам доведеться зробити фізичне видалення. Але для того, щоб зберегти всю історію облікового запису, ми завжди повинні архівувати такі записи або в архівних таблицях, або у видалених таблицях.

Так, у ситуаціях, коли у нас багато іноземних столів, обробка досить громіздка.

Також майте на увазі, що м'які / логічні видалення збільшать розмір вашої таблиці, тому розмір індексу.

Я вже відповів в іншому дописі . Однак я вважаю, що моя відповідь більше підходить до цього питання.

Моє практичне рішення для м'якого видалення є архівування шляхом створення нової таблиці з наступними стовпчиками: original_id, table_name, payload, (і додатковий первинний ключ `ідентифікатор).

Де original_idоригінальний ідентифікатор видаленого запису, table_name це ім'я таблиці видаленого запису ( "user"у вашому випадку), payloadце рядок JSON-рядка з усіх стовпців видаленого запису.

Я також пропоную зробити індекс на стовпчику original_idдля останнього пошуку даних.

Таким способом архівації даних. Ви матимете ці переваги

• Слідкуйте за всіма даними в історії
• Майте лише одне місце для архівації записів з будь-якої таблиці, незалежно від структури таблиці видалених записів
• Не хвилюйтесь за унікальний індекс у вихідній таблиці
• Не турбуйтеся перевірити іноземний індекс у вихідній таблиці
• У WHEREкожному запиті більше немає пункту перевірки на видалення

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

Переваги - це збереження / увічнення даних. Відхиленням буде зменшення продуктивності при запиті або виведенні даних із таблиць із значною кількістю м'яких делетів. У нашому випадку ми використовуємо комбінацію обох: як це згадували інші у попередніх відповідях, ми, soft-delete users/clients/customersнаприклад, і hard-deleteна items/products/merchandiseтаблицях, де є дублюються записи, які не потрібно зберігати.

Це залежить від випадку, врахуйте нижче:

Зазвичай запис не потрібно "м'яко видаляти". Зберігайте це просто і швидко. наприклад, Видалення продукту більше не доступне, тому вам не доведеться перевіряти, чи продукт не видаляється програмним забезпеченням у всьому додатку (кількість, список продуктів, рекомендовані продукти тощо).

Тим не менш, ви можете розглянути "м'яке видалення" в моделі сховища даних. Наприклад, ви переглядаєте стару квитанцію на видалений продукт. *