2013-03-02 2 views
1

많은 엔티티와 관계가있는 복잡한 스키마가 있습니다. 실행 취소 할 수있는 논리적 삭제 작업을 정의하려고합니다. 나는 모든 테이블에 'isDeleted'플래그를 추가하는 것을 고려해 봤지만, 나에게 버그가 있다고 보입니다. 또한 원래 스키마와 유사한 아카이브 스키마를 추가하는 것을 고려했으며, 데이터를 옮길 때마다 삭제 작업을 할 때마다 "삭제"및 "삭제 취소"작업을 작성하는 데 많은 코드가 필요합니다. espacially 논리적 delte에 대한 delete casade에서 에뮬레이트하고 싶기 때문에).DB에서 논리적 삭제

마지막으로 논리적 삭제 이벤트를 어디에 처리해야할지 모르겠다. EF를 사용하여 코드에서 수행 할 수 있습니다. 또는 DB에서 삭제 트리거를 사용할 수 있습니다.

우아한 방식으로 논리적 삭제를 구현하는 방법에 대한 권장 사항을 알려 드리겠습니다. 감사.

답변

3

내가 일한 모든 회사는 항상 논리 삭제 플래그를 사용하고 코드를 통해 관리했습니다. 아카이브 스키마를 추가하는 것은 엄청난 오버 헤드이며 IMO의 추가 된 elegancy (코딩과 성능면에서 모두)는 추가 작업을 할 가치가 없습니다.

+1

삭제 된 플래그의 단점은 삭제 작업에 노력을 저장하는 동안 모든 쿼리에 isDeleted = false 확인을 추가해야한다는 것입니다. –

+0

@omer schleifer 인덱스에 포함되어 있고 쿼리 범위에서 기본값 인 모든 DB의 '삭제 된'열은 훨씬 쉽고 데이터베이스가 아닌 코드에 비즈니스 논리를 넣을 수 있습니다. 삭제 된 기록을 복원하거나보기 만한다면 어떨까요? 그래서 나는 다른 시도가 과부하와 복잡성의 가치가 있는지 의심 스럽다. – YvesR

0

이것은 OLTP 데이터베이스이므로 IsDeleted 플래그를 사용하는 데 문제가 없습니다. 성능에 대해 걱정이된다면 IsDeleted 플래그를 계속 사용하고 온라인이 아닌 배치 프로세스를 통해 아카이브로 이동하십시오.

과도한 설계를 피하기 위해 항상 염두에 두어야 할 한 가지는 문제가 아니면 문제가되지 않습니다.

관련 문제