소프트 삭제는 좋은 생각입니까?

소프트 삭제는 좋은 생각입니까? [복제]

---

이 질문에는 이미 답변이 있습니다.

• 데이터베이스 레코드의 물리적 대 논리적 / 소프트 삭제? 답변 23 개

소프트 삭제는 좋은 아이디어입니까, 나쁜 아이디어입니까?

실제로 데이터베이스에서 레코드를 삭제하는 대신으로 플래그 IsDeleted = true를 지정하고 레코드를 복구하면으로 플래그를 지정할 수 있습니다 False.

이것이 좋은 생각입니까?

레코드를 실제로 삭제 한 다음 아카이브 데이터베이스로 이동하고 사용자가 레코드를 다시 원할 경우 소프트웨어는 아카이브에서 레코드를 찾아서 다시 작성하는 것이 더 좋은 아이디어입니까?

---

나는 일반적으로 (일부 예외를 제외하고) 나쁜 생각이라고 말합니다.

먼저 데이터베이스를 정기적으로 백업해야하므로 DELETE로 인해 데이터가 영구적으로 손실되는 상황에 처해서는 안됩니다 (물론 방금 추가 한 데이터를 삭제하지 않는 한).

둘째, 이와 같이 WHERE IsDeleted = false일시 삭제하면 이제이 테이블의 모든 쿼리에 절 을 포함해야 합니다 (이 테이블에 참여하는 경우 훨씬 더 나빠짐). 사용자 나 테스터가 삭제 된 레코드가 다시 표시되는 것을 발견하자마자 여기에서 실수가 발생하는데 시간이 걸릴 수 있습니다. 또한 개발자가 COUNT (*) 쿼리에서 WHERE 절을 생략하는 것이 더 쉬울 것입니다. 발견하는 데 시간이 더 오래 걸릴 수 있습니다. 따라서 총계는 예상치에 가깝고 아무도 눈치 채지 못했습니다.

마지막으로, 소프트 삭제는 인공 키가있는 테이블에서는 작동하지만 자연 기본 키가있는 테이블에서는 작동하지 않을 수 있습니다 (예 : 사회 보장 번호로 키가 지정된 테이블에서 누군가를 "삭제"합니다. "복합 기본 키에 IsDeleted 포함"이라고 말하지 마십시오.)

디자인 검토에서 개발자는 비용과 이점에 대한 인식을 보여주고 이러한 방식으로 소프트 삭제를 수행 하는 훌륭한 이유 를 제시 할 것으로 기대합니다 . "왜 하지 그것을?" 훌륭한 이유는 아닙니다.

---

잠재적 인 데이터 손실을 피하는 것은 결코 나쁜 생각이 아닙니다.

나는 항상 소프트 삭제합니다. 데이터베이스를 하나 이상의 레코드로 제거해야하는 경우 일반적으로 소프트 삭제의 2 단계 프로세스를 수행 한 다음 레코드의 "휴지통"을 비우거나 문서 레코드가 가능한 문서 관리 스타일 방식을 사용합니다. 노후된 다음 하드 삭제 전에 승인 프로세스를 거칩니다.

---

상황에 따라 다릅니다. 법적으로 무언가를 삭제해야하는 상황을 볼 수있었습니다. 누군가가 사회 보장 번호를 시스템에서 영구적으로 제거하도록 요청했을 수 있습니다. 또는 단일 레코드로 통합하려는 중복 레코드가있을 수 있습니다. 삭제 된 플래그를 사용하여 중복을 유지하는 것은 유리하지 않을 수 있습니다.

기술적 인 단점도 있습니다. 계단식 삭제를 수행 할 수 없으므로 외래 키 위반을 방지하기 위해 삭제 된 데이터에 대한 참조를 자동으로 지 웁니다. 이것은 반드시 큰 문제는 아니지만 명심해야 할 문제입니다.

그렇지 않으면 좋은 생각이라고 생각합니다.

---

소프트 삭제를 사용하려면 is_deleted 필드 대신 deleted_date 필드를 사용하는 것이 좋습니다. 비트 필드 대신 멋진 추가 데이터를 얻습니다.

---

소프트 삭제의 주요 문제점 중 하나는 원하지 않는 데이터가 잠재적으로 DB 성능에 영향을 줄 수 있다는 것입니다. 몇 년 전 내 고객 중 한 명이 모든 데이터베이스 항목에 대해 소프트 삭제를 요청했습니다. 이에 대한 해결책은 모든 "삭제 된"항목을 현재 실행중인 테이블에 두지 않고 백업 테이블로 옮기는 것입니다.

---

유효하지 않은 삭제가 절대적으로 치명적일 경우 복구는 간단해야합니다. 또한 지금까지 있었던 모든 것을 추적하고 "삭제"는 "숨기기"만 의미하는 것이 좋습니다. 의미는 상황에 달려 있습니다.

---

나는 "정치적으로 정직하게"노력하지 않을 것이다. 일시 삭제를 옹호하는 경우 뇌 검진을 받아야합니다.

1) 먼저, 테이블의 행을 삭제하지 않고 정확히 무엇을 달성하고 있습니까? 미래에 언젠가 그 행에 액세스 할 수 있다는 사실입니까? 그렇다면 왜 아카이브 테이블을 만들고 행을 거기로 옮기지 않겠습니까? 그게 뭐가 문제 야?

2) 일시 삭제를 사용하면 is_active에 불필요한 쿼리를 생성하거나 타임 스탬프 열에 쿼리를 생성합니다. 간단한 쿼리를 작성할 때 낭비입니다. 예, 뷰와 함께 작동하지만 뷰가 추가 부속물이 아닙니까? 모든 뷰는 별도의 SQL, 추가 성능 비용이며, 모든 상용 RDBMS에서 모든 것이 테이블에 불과합니다. 테이블 위에 쿼리를 작성하는 방법을 모른다는 사실 외에는 뷰에 대해 마술이 없습니다.

3) 예, View 또는 MV에서 작동합니다. 그러나 FTS를 수행하는 프로덕션에서 쿼리를 보았지만 모든 것이 여전히 작동합니다! 최신 하드웨어와 견고한 소프트웨어의 경이로움. 그러나 그것이 옳은 것은 아닙니다. 동일한 논리에 의해 작동한다고해서 그것이 옳다 는 것은 아닙니다.

4) 소프트 삭제의 복잡성은 결코 간단한 선택에서 멈추지 않습니다.

A) UNIQUE 제약 조건이 있다고 가정하십시오. 이제 행을 일시 삭제하지만 UNIQUE 제약 조건이있는 열은 여전히 ​​존재합니다. 동일한 데이터를 다시 추가하려면 추가 "트릭"이 없으면 수행 할 수 없습니다.

B) 테이블 A에서 테이블 B 로의 연관이있을 수 있으며 테이블 A에서 무언가를 삭제하는 경우 테이블 B에 대한 독립적 인 조회가 해당 사실을 처리하도록해야합니다. 일반적인 세부 사항 페이지가 detail_id에서 작동한다고 가정하십시오.

이제 master_id는 소프트 삭제되지만 여전히 모든 master_id의 detail_id를 가진 영구 링크가 있습니다. master_id에서 하드 삭제를 수행하면 해당 세부 정보가 존재하지 않습니다. 이제 소프트 삭제를 사용하면 여전히 존재하며 master_id가 소프트 삭제 모드에 있다는 사실을 알고 있어야합니다.

간단한 Table_A.is_active = 0 또는 1 단계에서 멈추지 않습니다.

5) 강제 삭제는 간단하고 옳습니다.

A) 누구도 추가하거나 걱정할 것이 없습니다.

1. 응용 프로그램 논리가 더 간단합니다
2. 데이터베이스가 더 작습니다
3. 쿼리가 더 빠릅니다

데이터 + 관련 조각을 보관하면 좋을 것입니다.

---

일시 삭제를 사용하면 응용 프로그램에서 사용하는 데이터베이스 계정에서 권한 을 취소 할 수도 있습니다 DELETE.

---

때때로 소프트 삭제가 필요합니다. 예를 들어 Products 테이블을 참조하는 Invoice 테이블이 있다고 가정하십시오. 특정 제품으로 인보이스를 만든 후에는 해당 제품을 삭제할 수 없습니다 (RI가 올바르게 설정되어 있으면 허용되지 않음).

이 특정 시나리오에서는 실제 회사에서는 과거 재무 데이터를 삭제하고 싶지 않은 송장을 절대로 삭제하지 않을 것이라고 가정합니다.

Though there are many other cases where you would not be able to delete some data as a side effect of a dependency up the chain not being deletable for reasons business or other.

---

It depends on the data. Some data cannot be deleted due to legal/audit requirements.

Social networking sites on the other hand should provide an option to delete an account with all associated data, including contact info, photos, messages, etc. It's a real annoyance if they don't, e.g. Facebook.

---

in oracle, if you add the primary key to a recycle_bin table you make up, then add a row level security policy, you can suppress the values from all queries when the row is in the recycle bin, removing the pk from the recycle bin will automatically restore all data. no need to change your other queries to accomodate the logic.

---

It comes with a cost, though, because you need to update your queries and indexes to be able to exclude the deleted rows.

Maybe instead of toggling a flag, move it to another "trash can" table.

Also, one could say that is only a partial solution, because it covers only deletes, but when you update a row, you are still overwriting the old value.

In general, I'd say never delete anything unless you really have to. Disk space is cheap these days. Of course, there are limits, there is data that you are legally bound to erase, there is data that is really not all that important, and maybe you do not need to keep the old data online and in the same table (an archive somewhere would also work).

---

Just to add a cent. I always soft-delete; though it does cost the performance, but very slightly. Think about the cost, when your customer complains regarding your software that stopped functioning after she performed certain actions that even she can't remember. Well, this may be a fat example, but you would never know what went wrong, who did what, what was before and what was inserted afterwards. In that case this would come handy. This functionality comes handy for auditing purpose, and many a customer requests for auditing reports of this sort.

Also, in most workflow based applications, it comes as a software feature/requirement that customer is interested in the "actions" performed on a work item; what values were assigned and who processed it, etc.

---

I am a fan of soft-deletes. Primarily to prevent cascading deletes. However, it takes additional code so that if you are SELECTing a child object, it joins to the parent (and all parent!) objects to make sure none of them are deleted. Alternatively you can cascade the soft-delete, but if you want to restore them later you may not know which children had already been deleted and which were deleted due to the cascade.

Additionally, I keep a revision date time and revision username on each object, so that I know who modified (or soft-deleted) it last. Then for an audit trail, I create a *History (like CustomerHistory) table that is inserted after every UPDATE to the original table. This way after an object is modified or soft-deleted, I have a record of who performed the action as well as the last known state of the object.

---

I encountered soft-deletes for the following broad scenarios:

CASE 1: remove the record from being user/code visible, but have the record at the DB level since the business is interested in knowing it had that records.
These requirements are mostly driven by the business & usually at the core is perhaps a legal requirement (like @joshperry & @armandino scenarios) to have the previous record in the database & create a new record for every change made. At this point, I would look at CASE 2 & evaluate if it satifys the requirements before having an IsDeleted flag

CASE 2: audit trails to keep track of the evolution of a record - there are tons of decent articles online for keeping audit trails of records in a database

HTH.

참고URL : https://stackoverflow.com/questions/2549839/are-soft-deletes-a-good-idea