2012-07-01 4 views
4

잠시 동안 연구했지만 적절한 대답을 얻을 수없는 데이터베이스 디자인 문제가 있습니다. 이제 우리는 다음과 같은 두 개의 테이블 house_schemahouse 있다고 가정 해 봅시다 : house다른 테이블의 속성을 저장하는 하나의 테이블에서 레코드 삭제

house_schema { 
     id big int, 
     house_height int, 
     house_width int, 
     house_decoration vchar(1024), 
     build_date timestamp, 
     primary key id, 
} 

house { 
     id big int, 
     owner vchar(255), 
     price big int, 
     house_schema_id big int, 
     primary key id, 
     foreign key fk_house_house_schema_id (`house_schema_id`) reference `house_schema`.`id` 
} 

house_schema 테이블에는 몇 가지 물리적 특성. 소프트웨어 UI에서 사용자는 스키마를 선택한 다음 "빌드"버튼을 클릭합니다. 주택은 건설되어 house에 저장됩니다. 주택 건설 방법을 설명하는 house_schema과 같은 다른 테이블이 있습니다.

단순한 디자인으로 외장 키가 잘 작동하는 것처럼 보입니다. 그러나 빌더가 오래되었다고 생각하는 스키마를 제거하기로 결정하면 문제가 발생합니다. 이미 스키마에서 빌드 된 일부 집이 있으며 외래 키로 삭제할 수 없습니다. 외래 키를 DELETE ON CASCADE으로 변경하면 해당 주택은 그것이 구축 된 정보를 잃게됩니다.

이 문제를 해결하는 가장 좋은 디자인 패턴은 무엇입니까? 내가 상상할 수있는 것은 house_schema이라는 중복 테이블을 가지고있는 것입니다. 집이 만들어지면 house_schema에있는 행을 복제 테이블에 복사하십시오.

그러나 house_schema과 유사한 테이블이 여러 개 있기 때문에 데이터베이스에 중복 테이블이 많이 생깁니다. 그것은 데이터베이스 정규화 규칙을 위반하는 것 같습니다.

누구에게 좋은 생각이 있습니까?

답변

3

집을 짓는 데 사용 된 스키마의 기록을 유지하려는 경우 일반적인 해결 방법은 house_schema 테이블에 소프트 삭제를 구현하는 것입니다.

대신

  • false에 테이블에
  • 설정이 열을 Active 열을 추가하려면 스키마는
  • 하지에 응용 프로그램을 조정되지 않는 경우 실제로 house_schema의 행을 삭제하는 당신은 것 비활성 스키마보기

부드러운 삭제에 대해 꽤 많은 자료가 있습니다. 둘 다 ag ainst 및 for. The trouble with soft delete

  • 개인적인 경험에서 Soft deletes are bad?
  • Are soft deletes a good idea

    • , 우리가 부드러운 지금까지 어떤 mentionable 문제없이 우리의 주요 응용 프로그램에서 선택 가능한 항목 (드롭 다운 목록을)에 삭제 사용합니다.

      항목이 쓸모 없어지면 그 값은 사용되는 곳마다 유지해야하지만 새 문서의 경우에는 더 이상 드롭 다운 목록에 나타나서는 안됩니다. 나는 아직이 시나리오를 다룰 수있는 더 좋은 해결책을 찾아야한다. 소프트 삭제보다.

  • 0

    몇 가지 가능성이 있습니다

    • 당신은 스키마를 표시하기 위해 플래그가 더 이상 존재하지 않는 것 house_schema에서 "삭제"필드를 가질 수있다. 이는 많은 쿼리를 변경하는 것을 의미합니다.

    • "삭제 불가능한"기본 스키마가있을 수 있습니다.이 스키마는 삭제 될 때 해당 하우스가 다시 폴백됩니다.

    0

    간단한 해결책으로 "deleted"플래그를 house_schema에 추가 할 수 있습니다. 그렇게하면 역사적인 항목을 유지할 수 있습니다. 사용 가능한 house_schema 항목을 사용자에게 표시 할 때 삭제되지 않도록 필터링하십시오.

    0

    아마도 "deprecated_schema"를 추가 할 수 있습니다. 여기서 "deprecated_schema"는 삭제 될 house_schema 행을 단순히 비추천 부분으로 복사하는 것입니다. 원래 house_schema ID 필드를 저장하는 필드가 필요하므로 하우스 테이블에서 올바른 항목을 계속 얻을 수 있습니다.

    그런 다음 house_schema 테이블에서 삭제할 수 있으며 해당 스키마를 기반으로하는 집에 계속 액세스 할 수 있습니다.

    0

    다른 관점을 추가하기 만하면 * house_schema *에 저장된 세부 정보가 사실 집인의 속성이며 실제로 저장해야한다고 생각 했습니까?
    이것은 과다 정규화의 경우로 볼 수 있습니다.

    +0

    집을 짓기 전에 스키마를 구성하기 때문에 스키마를 별도의 테이블에 저장합니다. 사용자가 구성을 선택하면 집이 구성되어 이제 구성이 집의 속성이됩니다. 하지만 그 전에는 집이 있기 때문에 어쨌든 속성이 아닙니다. –

    관련 문제