Best Practice(PHP/MySQL) 소프트 삭제

Best Practice(PHP/MySQL) 소프트 삭제

문제

저는 제품과 주문을 다루는 웹 애플리케이션에서 전직 직원(사용자)과 그들이 취급한 주문 사이의 정보와 관계를 유지하고 싶습니다.저는 오래된 제품과 이 제품들이 포함된 주문 사이의 정보와 관계를 유지하고 싶습니다.

하지만 저는 직원들이 이전 직원, 오래된 제품, 오래된 제품 그룹 등을 제거하는 등의 관리 인터페이스를 차단할 수 있기를 바랍니다.

소프트 삭제를 시행할 생각입니다.그렇다면 보통 어떻게 하는 것일까요?

나의 즉각적인 생각들

내 첫번째 생각은 ""을 붙이는 것입니다.flag_softdeletedTINYINT NOT NULL DEFAULT 0" 열은 소프트 삭제 가능해야 하는 모든 개체 테이블에 있습니다.아니면 타임스탬프를 대신 사용할 수도 있습니까?

그런 다음 각 관련 GUI에 "삭제된 표시" 또는 "삭제 취소" 버튼을 제공합니다.이 버튼을 클릭하면 소프트 삭제된 레코드가 결과에 포함됩니다.삭제된 각 레코드에는 "Restore" 버튼이 있습니다.이게 말이 됩니까?

당신의 생각은?

그리고 관련 자료에 대한 링크도 부탁드립니다.

저는 그렇게 합니다.는을 가지고 .is_deleted기본값이 0인 필드입니다.그럼 조회만 하면 됩니다.WHERE is_deleted = 0.

저는 가능한 한 어떤 어려운 사람들과도 멀리하려고 노력합니다.필요할 때도 있지만 관리자 전용 기능으로 만들고 있습니다.그렇게 하면 삭제는 할 수 있지만 사용자들은...

편집: 실제로 앱에서 여러 개의 "계층" 소프트 삭제 기능을 사용할 수 있습니다.그래서 각각은 코드가 될 수 있습니다.

• 0되지 않음->음
• 1-> Soft Delete, 관리 사용자의 삭제된 항목 목록에 표시
• 2 Delete,되지 않음-> Soft Delete,n.
• 3-> 개발자에게만 나타납니다.

다른 두 단계를 사용해도 관리자와 관리자는 너무 오래 걸릴 경우 삭제된 목록을 정리할 수 있습니다.그리고 프론트엔드 코드가 단지 확인하는 것이기 때문에is_deleted = 0 하고 까지 하고 까지 ...

소프트 삭제를 사용하는 것은 일반적인 구현 방법이며, 다음과 같은 많은 작업에 유용합니다.

• 사용자가 무언가를 삭제했을 때 사용자의 데이터 저장
• 무언가를 삭제할 때 자신의 데이터 저장
• 실제 발생한 일(일종의 감사)을 기록합니다.
• 등세테라

한 가지 지적하고 싶은 것이 있는데, 거의 모든 사람들이 놓치는 것은 항상 뒷편에서 당신을 물어뜯기 위해 돌아옵니다.응용프로그램의 사용자는 사용자와 동일하게 삭제를 이해하지 못합니다.

삭제 정도가 다릅니다.일반적인 사용자는 (s)그가 (s)그가 (s)그가

• 실수를 해서 잘못된 데이터를 제거하려고 합니다.
• 화면에서 더 이상 무언가를 보고 싶지 않음

문제는 삭제 의도를 기록하지 않으면 애플리케이션이 오류 데이터(생성되지 말았어야 하는)와 과거의 올바른 데이터를 구분할 수 없다는 것입니다.

다음 데이터를 살펴봅니다.

PRICES | item | price | deleted |
       +------+-------+---------+
       |   A  |  101  |    1    |
       |   B  |  110  |    1    |
       |   C  |  120  |    0    |
       +------+-------+---------+

일부 사용자는 B 아이템을 더 이상 판매하지 않기 때문에 가격을 보여주기를 원하지 않습니다.그래서 삭제를 합니다.다른 사용자가 실수로 A 아이템에 대한 가격을 만들어 의도대로 삭제하고 C 아이템에 대한 가격을 만들었습니다.이제 모든 제품의 가격표를 보여주시겠습니까?아니요, 오류가 있을 가능성이 있는 데이터(A)를 표시하거나 현재 가격(C)을 제외한 모든 값을 제외해야 하기 때문입니다.

물론 위의 내용은 다양한 방법으로 다룰 수 있습니다.제 요점은 삭제의 의미를 매우 명확히 해야 하며, 사용자가 이를 오해할 수 있는 방법이 없는지 확인해야 한다는 것입니다.한 가지 방법은 사용자가 선택(숨기기/삭제)하도록 강요하는 것입니다.

그 테이블에 맞는 기존 코드가 있다면 열을 추가하고 테이블의 이름을 변경할 것입니다.그러면 활성화된 레코드만 선택하는 현재 테이블과 같은 이름의 뷰를 작성하겠습니다.그러면 기존 코드가 깨지지 않고 소프트 삭제 열을 가질 수 있습니다.삭제된 레코드를 보려면 기본 테이블에서 선택하고, 그렇지 않으면 보기를 사용합니다.

저는 당신이 말한 대로 항상 삭제된 칼럼을 사용했습니다.그것보다 더 많은 것은 정말 없습니다.레코드를 삭제하는 대신 삭제된 필드를 true로 설정합니다.

일부 구성요소는 사용자가 삭제된 모든 레코드를 보고 복원할 수 있도록 하고, 다른 구성요소는 삭제된 모든 레코드만 표시합니다. = 0

당신의 아이디어는 정말 말이 되고 제작에 자주 사용되지만, 그것을 구현하기 위해서는 새로운 분야를 고려하여 코드를 꽤 많이 업데이트해야 할 것입니다.또 다른 옵션은 "소프트 삭제된" 레코드를 별도의 테이블이나 데이터베이스에 보관(이동)하는 것입니다.이 또한 자주 수행되며, (재)프로그래밍이 아닌 유지보수의 문제가 됩니다. (삭제된 레코드를 보관하기 위해 테이블 트리거가 삭제에 반응하도록 할 수 있습니다.)

생산 코드에 대한 대대적인 업데이트를 피하기 위해서 보관을 하겠습니다.그러나 삭제된 필드를 사용하려면 타임스탬프로 사용하여 부울 이상의 유용한 정보를 추가로 제공합니다. (Null = not deleteed.)레코드 삭제를 담당하는 사용자를 추적하기 위해 DeleteedBy 필드를 추가할 수도 있습니다.두 개의 필드를 사용하면 누가 언제 무엇을 삭제했는지 알 수 있습니다. (두 개의 추가 필드 솔루션은 아카이브 테이블/데이터베이스에서 수행할 수도 있습니다.)

가장 흔한 시나리오는 당신이 설명하는 것입니다.tinyint또는 심지어bit의 상태를 나타냄IsActive아니면IsDeleted. 이 데이터가 "비즈니스" 또는 "지속성" 데이터로 간주되는지에 따라 애플리케이션/도메인 로직(예: 저장 프로시저에 직접 저장되어 있고 애플리케이션 코드에 알려지지 않은 것과 같이)에 최대한 투명하게 구워질 수 있습니다.하지만 이것은 당신의 요구에 맞는 합법적인 비즈니스 정보로 들리기 때문에 코드 전반에 걸쳐 알아야 합니다.(사용자가 제안하는 대로 삭제된 레코드를 볼 수 있습니다.)

제가 본 또 다른 접근법은 두 타임스탬프의 조합을 사용하여 주어진 레코드에 대한 "활동 시간대"를 보여주는 것입니다.유지하기에는 조금 더 코드가 있지만, 미리 정해진 시간에 소프트 삭제를 예약할 수 있다는 장점이 있습니다.제한된 시간의 상품은 예를 들어, 그것이 생성될 때 그렇게 설정될 수 있습니다.(음반을 무한히 활성화하려면) 최대값을 사용하거나(또는 터무니없이 먼 미래의 날짜를 사용할 수 있습니다), 또는 종료 날짜는 다음과 같습니다.null괜찮으시다면요.)

그런 다음 때때로 삭제/삭제 취소를 고려하고 이에 대한 일종의 감사를 추적할 수 있습니다.플래그 접근법은 현재 상태만 알고 타임스탬프 접근법은 가장 최근 창만 알고 있습니다.그러나 감사 기록처럼 복잡한 것은 문제가 된 기록과는 분명히 별도로 저장되어야 합니다.

대신 다른 테이블에서 삭제된 모든 레코드를 이동하는 빈 테이블을 사용하겠습니다.삭제 플래그의 가장 큰 문제는 링크된 테이블에서 새 레코드를 삽입할 때 이중 키 오류가 발생한다는 것입니다.

빈 테이블은 다음과 같은 구조를 가질 수 있습니다.

id, table_name, data, date_time, user

어디에

• id는 자동 증분이 있는 기본 키입니다.
• table_name은 레코드가 삭제된 테이블의 이름입니다.
• 데이터에는 모든 필드의 이름과 값을 가진 JSON 형식의 레코드가 포함됩니다.
• date_time은 삭제 날짜 및 시간입니다.
• user는 작업을 수행한 사용자(시스템에서 제공하는 경우)의 식별자입니다.

이 방법을 사용하면 각 쿼리에서 삭제 플래그를 확인하는 것을 방지할 수 있을 뿐만 아니라 테이블에 실제로 필요한 데이터만 가지고 SQL 클라이언트 프로그램을 사용하여 검색 및 수정을 용이하게 할 수 있습니다.

언급URL : https://stackoverflow.com/questions/5020568/soft-delete-best-practices-php-mysql