SQL Server에서 외래 키를 설정할 때 어떤 상황에서 삭제 또는 업데이트시 계단식으로 연결해야하며 그 이유는 무엇입니까?
이것은 아마도 다른 데이터베이스에도 적용됩니다.
나는 각 시나리오의 구체적 예를 위해 무엇보다도 가장 바람직하게 그것을 사용하는 사람으로부터 찾고 있습니다.
답변
지금까지 본 내용 요약 :
- 어떤 사람들은 계단식을 전혀 좋아하지 않습니다.
캐스케이드 삭제
- Cascade Delete는 관계의 의미론이 독점적 인 “설명의 일부”를 포함 할 수있을 때 의미가있을 수 있습니다 . 예를 들어, OrderLine 레코드는 상위 주문의 일부이며 OrderLine은 여러 주문간에 공유되지 않습니다. 주문이 사라 졌다면, 주문 라인도 주문해야하며, 주문이없는 라인은 문제가됩니다.
- Cascade Delete의 일반적인 예는 SomeObject 및 SomeObjectItems입니다. 여기서 해당 주 레코드가 없으면 항목 레코드가 존재하지 않습니다.
- 당신은해야 하지 당신이 역사를 보존 또는 사용하는 경우 삭제 캐스케이드를 사용하여 “소프트 / 논리적 삭제”당신은 단지 1 / true로 삭제 된 비트 열을 설정 한 경우.
캐스케이드 업데이트
- 계단식 업데이트는 테이블에서 서로 게이트 키 (ID / 자동 증가 열)가 아닌 실제 키를 사용하는 경우에 적합합니다.
- Cascade Update의 일반적인 예는 사용자 이름과 같이 변경 가능한 외래 키가있는 경우입니다.
- ID / 자동 증가 열인 키와 함께 계단식 업데이트를 사용 해서는 안됩니다 .
- 캐스케이드 업데이트는 고유 제한 조건과 함께 사용하는 것이 가장 좋습니다.
계단식 사용시기
- 작업을 캐스케이드하기 전에 사용자로부터 다시 강력한 확인을 받고 싶을 수도 있지만 이는 응용 프로그램에 따라 다릅니다.
- 외래 키를 잘못 설정하면 계단식 배열로 인해 문제가 발생할 수 있습니다. 그러나 그렇게하면 괜찮을 것입니다.
- 계단식을 이해하기 전에 계단식을 사용하는 것이 현명하지 않습니다. 그러나이 기능은 유용한 기능이므로 시간을내어 이해해야합니다.
답변
외래 키는 데이터베이스의 참조 무결성을 보장하는 가장 좋은 방법입니다. 마술이기 때문에 캐스케이드를 피하는 것은 컴파일러의 마술을 신뢰하지 않기 때문에 모든 것을 어셈블리에 쓰는 것과 같습니다.
나쁜 것은 외래 키를 뒤로 만드는 것과 같이 외래 키를 잘못 사용한다는 것입니다.
Juan Manuel의 예제는 정식 예제입니다. 코드를 사용하면 데이터베이스에 가짜 DocumentItem을 남길 가능성이 더 높습니다.
계단식 업데이트는 예를 들어 사용자 테이블의 기본 키가 이름, 성 조합과 같이 변경할 수있는 것으로 데이터를 참조 할 때 유용합니다. 그런 다음 해당 조합의 변경 사항이 참조되는 곳으로 전파되기를 원합니다.
@Aidan, 당신이 말하는 그 명확성은 비용이 많이 들지 않습니다 . 데이터베이스에 가짜 데이터를 남길 수 있습니다 . 저에게는 보통 DB에 익숙하지 않으며 DB를 사용하기 전에 어떤 FK가 있는지 파악할 수 없기 때문에 그러한 두려움이 생깁니다. 개체가 개념적으로 관련되지 않았거나 역사를 보존 해야하는 곳에서 캐스케이드를 계속 사용하거나 연속적으로 잘못 사용합니다.
답변
계단식 삭제를 사용하지 않습니다.
데이터베이스에서 무언가를 제거하려면 원하는 것을 데이터베이스에 명시 적으로 말하고 싶습니다.
물론 그것들은 데이터베이스에서 사용할 수있는 함수이며, ‘order’테이블과 ‘orderItem’테이블이있는 경우 데이터베이스를 삭제할 때 항목을 지우고 싶을 때 사용할 수 있습니다. 주문.
나는 ‘매직’이 아닌 코드 (또는 저장 프로 시저)에서 수행하는 명확성을 좋아합니다.
같은 이유로 나는 트리거 팬도 아닙니다.
주의 할 점은 ‘주문’을 삭제하면 계단식 삭제에서 ‘orderItem’이 50 개를 제거하더라도 ‘1 행 영향’보고서가 다시 표시됩니다.
답변
계단식 삭제로 많은 작업을 수행합니다.
데이터베이스에 대해 작업하는 사람이 원치 않는 데이터를 남기지 않을 수 있다는 것을 아는 것이 좋습니다. 종속성이 커지면 Management Studio의 다이어그램에서 제약 조건을 변경하기 때문에 sp 또는 데이터 액세스를 조정할 필요가 없습니다.
즉, 계단식 삭제와 순환 참조에는 1 가지 문제가 있습니다. 이는 계단식 삭제가없는 데이터베이스 부분으로 이어지는 경우가 많습니다.
답변
많은 데이터베이스 작업을 수행하고 계단식 삭제가 유용한 경우는 거의 없습니다. 내가 효과적으로 사용한 것은 야간 작업에 의해 업데이트되는보고 데이터베이스에 있습니다. 마지막 가져 오기 이후에 변경된 최상위 레코드를 삭제 한 다음 수정 된 레코드 및 관련 레코드를 다시 가져 와서 변경된 데이터를 올바르게 가져옵니다. 데이터베이스의 맨 아래에서 맨 위까지 보이는 많은 복잡한 삭제를 작성하지 않아도됩니다.
캐스케이드 삭제는 데이터를 삭제하기 때문에 트리거만큼 나쁘지 않다고 생각하지 않습니다. 트리거에는 모든 종류의 불쾌한 물건이 포함될 수 있습니다.
일반적으로 실제 삭제를 피하고 논리적 삭제 (즉, isDeleted라는 비트 열이 true로 설정 됨)를 대신 사용하십시오.
답변
예를 들어 엔터티 간 종속성이있는 경우를 예로들 수 있습니다. 예 : Document-> DocumentItems (Document를 삭제할 때 DocumentItems는 존재할 이유가 없습니다)
답변
참조 PK 레코드가 제거 된 경우 FK가있는 레코드를 제거하려는 경우 계단식 삭제를 사용하십시오. 다시 말해, 참조 레코드없이 레코드가 의미가없는 경우입니다.
캐스케이드 삭제는 null 예외를 발생시키지 않고 기본적으로 죽은 참조를 제거하는 데 유용합니다.
