데이터베이스에서 데이터를 삭제해야합니까?

데이터베이스를 처음 사용하고 기본 개념을 이해하려고합니다. 데이터베이스에서 데이터를 삭제하는 방법을 배웠습니다. 그러나 내 친구 중 한 명이 데이터베이스의 데이터를 절대 삭제해서는 안된다고 말했습니다. 오히려 더 이상 필요하지 않은 경우 간단히 표시하거나 '사용하지 않음'으로 표시하는 것이 좋습니다.

그게 사실입니까? 그렇다면 IBM과 같은 대기업이 백 년 이상 데이터를 어떻게 처리할까요?

이 모든 것들과 마찬가지로 대답은 "의존적"입니다.

사용자가 데이터를 다시 원할 경우 친구가 옳습니다. 실제로 레코드를 "삭제됨"으로 표시하지는 않습니다. 이렇게하면 사용자가 마음을 바꾸면 데이터를 복구 할 수 있습니다.

그러나 삭제 된 데이터가 특정 기간 (예 : 1 년)을 초과하는 경우 실제로 라이브 테이블에서 데이터를 삭제하지만 아카이브 테이블에 보관하거나 사용자가 원하는 경우에만 백업하기로 결정할 수 있습니다. 다시. 이러한 방식으로 데이터 양 (실시간 및 최근 삭제)을 최소로 유지할 수 있습니다.

그러나 데이터가 일시적이거나 쉽게 재생성되는 경우 실제로 데이터를 삭제하기로 결정할 수 있습니다.

삭제 해야 할 데이터에는 한 가지 클래스가 있으며 , 사용자가 더 이상 보유하고 싶지 않은 개인 데이터입니다. 이를 의무 요건으로 만드는 현지 법률 (예 : EU)이있을 수 있습니다 ( Gavin 감사 )

마찬가지로 데이터를 삭제 하지 않아도되는 규칙이있을 수 있으므로 법을 준수하기 위해해야 ​​할 일에 대해 규제 당국에 확인해야 할 사항이 있습니다.

이것은 실제로 많은 회사에서 중요한 문제입니다. 실제로 사용중인 데이터를 명확하게 확인할 수있는 방법은 없으므로 데이터베이스에 있습니다. 데이터 삭제 및 아카이빙은 모든 대규모 시스템 설계의 일부일 필요는 없지만 거의 그렇지 않습니다. 대부분의 회사는 시스템을 변경하고 현재 데이터를 식별 한 다음 해당 레코드를 새 시스템으로 마이그레이션하기 위해 상당한 노력을 기울일 때까지 더 큰 디스크를 구입하고 성능을 유지하기 위해 쿼리와 인덱스를 조정하는 것과 함께 살고 있습니다.

예, 데이터베이스에서 데이터를 삭제 해야 하지만, 언제, 언제 무엇을 말하는지는 간단하지 않습니다.

이미 "상황에 따라 다름"으로 귀결되는 좋은 답변이 이미 많았으며 이에 대한 답변을 추가 할 수 없습니다.

그러나 언급하지 않은 한 가지 언급해야 할 것은 시퀀스 또는 AUTO_INCREMENT 시스템에 의해 생성 된 기본 키를 절대 재사용해서는 안된다는 것입니다.

이러한 시스템에 의해 기본 키가 할당 된 항목을 삭제하면 기본 키 열에 삭제 된 데이터가 남는 간격이 생깁니다. 이러한 차이를 새 항목에 추가 할 때 새 항목에 재 할당하거나 기존 데이터를 섞어 새 ID를 제공하여 공백을 제거하려는 유혹이 있지만 그렇게하면 문제가 발생할 수 있습니다 방금 열쇠를 내버려두면 다룰 필요가 없습니다.

재주문 소모품 관리를 위해 프린터 데이터베이스를 유지한다고 가정 해보십시오. 오래된 레이저 프린터 인 프린터 13은 경제적 인 수리를 넘어 분해되어 버립니다. 한편, 관련이없는 이유로 누군가가 창고에서 바코드 인쇄를 위해 새 감열 식 프린터를 주문하고 그 프린터는 프린터를 교체하기 전에 도착합니다. 관리자는 새 프린터를 데이터베이스에 기록합니다. ID를 재활용하는 경우 새 감열 식 프린터에는 ID가 13으로 할당됩니다.

이제 누군가 프린터 13에 잉크가 거의 없다고 알려줍니다. 프린터 13은 레이저 프린터이므로 데이터베이스에서 프린터를 검색하지 않아도되고 토너 카트리지를 주문해야합니다. 프린터 13은 더 이상 레이저 프린터가 아니기 때문에 감열 잉크 팩을 주문해야합니다. 토너 카트리지가 도착하면 프린터의 잉크 리필이 잘못되어 사용할 수 없습니다. 더 이상 바코드를 인쇄 할 수 없으며 배송 대기중인 주문을 배송 할 수 없습니다.

더 나쁜 것은, 프린터 13을 삭제하고 그 이후에 나오는 모든 프린터를 틈새를 채우기 위해 섞으면 어떻게됩니까? 프린터 14 (일부 낡은 도트 매트릭스)는 프린터 13이되고 프린터 15는 프린터 14가됩니다.

모든 프린터에는 레이블이있어 데이터베이스와 상호 참조 할 수 있지만 이제 모든 레이블이 오래되었습니다. 일주일 내내 사업에있는 모든 프린터를 찾아 (수백 개가 될 수 있음) 레이블을 다시 지정해야합니다. 그것은 효과적인 시간 활용이 아닙니다. 또한 오류가 발생하기 쉬운 프로세스이며 완료되지 않은 경우 어떻게됩니까? 누군가 프린터 14가 고장 나고 긴급하게 수리해야한다고 전화를 걸어 프린터 14가 잉크젯 프린터라는 것을 알게되었습니다. 주위에 ID를 섞었기 때문에 실제로 도트 매트릭스 프린터가 시급히 수정되어야합니다. 문제를 일으킨 사람은 교수형에 처해있는 반면, 접수 원은 기술 지원 담당자가 있었지만 끊어지지 않은 프린터를 수리하기 위해 전화를 걸지 않았습니다.

자동 증분 시스템에 의해 할당 된 ID는 영구적 인 것으로 생각해야하며, ID가 참조하는 것이 존재하지 않더라도 변경할 수 없으며 재사용 할 수 없습니다. 일부 사람들은 ID가 부족할 염려가 없다고 주장하지만 32 비트 시스템 및 서명 된 ID를 사용하더라도 여전히 20 억 개 정도의 ID를 사용할 수 있습니다. ID 열을 부호없는 것으로 만들 수 있다면 이것은 40 억으로 두 배가되며 64 비트 시스템에서 사용 가능한 ID의 수는 문자 그대로 하늘의 별 수보다 큽니다. ID가 부족하지 않습니다.

여기에 좋은 답변이 많이 있습니다. 아직 아무도 언급하지 않은 상황을 하나 추가하고 싶습니다.

민감한 데이터 . 사용자가 삭제하면 실제로 삭제하는 것이 좋습니다.

가장 일반적인 상황은 비밀번호 변경 / 재설정입니다. 데이터베이스에 이전 비밀번호 (해시, 솔트 등)를 저장하고 싶지 않습니다. 사용자가 다른 사이트에서 이전 (잘못된) 암호를 사용하고있을 수 있습니다.

또한 특정 유형의 데이터를 얼마나 오래 저장할 수 있는지에 관한 법률에 관해서는 물론 소프트 삭제는 수행하지 않습니다. 실제로 삭제해야합니다.

그래서 나는 나 자신에게 물을 것입니다 : 데이터가 삭제되었다고 생각하게하면 사용자 (또는 다른 정부, 예를 들어 정부)가 화를 낼 것이지만 실제로는 여전히 그것을 가지고 있으며 언제든지 복원 할 수 있습니까?

일반적으로 데이터베이스에서 사용자 데이터를 제거하지 않습니다. 숨겨 지도록 신고합니다. 너무 자주 사용자가 실수로 무언가를 삭제하고 쉽게 교체해야합니다. 또한 관련 데이터에 대한 참조 무결성을 유지하는 데 도움이됩니다. 중소 규모의 데이터베이스에서 작동합니다. 이 결정에 의해 성능이 크게 영향을받는 시스템에서는 아카이브 테이블, 자동 백업 등과 같은 특별한 방식으로 처리됩니다.

필요에 따라 백엔드 데이터 (예 : 만료 된 웹 사이트 세션 데이터 및 오래된 로그 정보)를 버립니다. 그것들을 영원히 지키는 데는 아무런 의미가 없습니다.

그러나 평소와 같이 정확한 답변은 특정 상황에 따라 다릅니다.

나는 이것이 일어난 몇 년 동안 외환 응용 프로그램에서 일해 왔습니다. 응용 프로그램이 수년에 걸쳐 수집 한 데이터는 성능에 영향을 미쳤습니다 (예 : 지수).

코드 측면에서 우리가 할 수있는 일을 완료 한 후 1 년보다 오래된 데이터를 보관하기 위해 관리 부서에 제안했습니다. 그들은 개념 (법적 문제)을 확인했고 운 좋게도 우리는 그것을 할 수있었습니다. 그래서 우리는 삭제했지만 비즈니스가 보고서 등을 계속 실행할 수 있도록 데이터를 보관했습니다.

대부분의 경우 미래에 필요할 경우를 대비하여 데이터를 보관해야합니다. 당신이 일하는 사업체는 회사를 특정 방향으로 이끌 수있는 결정에 근거하여 과거 데이터를보고 싶을 수 있습니다.

각 테이블에 'Date_Time_Removed'열을 추가 한 다음 행을 실제로 삭제하는 대신 행이 실제로 삭제 된 날짜와 시간을 설정해야합니다. 그런 다음 저장 프로 시저 또는 SQL에서 'Date_Time_Removed'열을 고려합니다. 예를 들어 date_time_removed가 null 인 table1에서 blah를 선택하십시오.

물론 데이터베이스에 실수로 추가 된 행, 특히 테스트 데이터는 영구적으로 제거해야합니다.

모든 합법적 인 데이터를 유지함으로써 차후에 창고에 데이터베이스를 사용할 수도 있습니다.

제시된 다른 상황은 데이터가 삭제되는 경우이지만 데이터베이스 (삭제 포함)에서 수행 된 작업 로그는 오랫동안 아카이브에 저장됩니다. 이것의 주요 범위는 과거 날짜까지 롤백 시스템을 구현하는 것이지만 삭제 된 데이터 (데이터베이스에서 삭제되었지만 아카이브에 저장 됨)를 저장하는 데 사용될 수도 있습니다.

삭제 된 데이터의 아카이브를 저장하는 것은 그리 큰 일이 아닙니다. 대기업은 또한 코드 버전과 더 많은 정보 (기술적으로 관련되지 않은 내용에 대해서는 이야기하지 않음)를 저장할 수 있으므로 결국에는 큰 데이터를 저장하는 것이 일반적입니다.