SQL Server에서 Cascading을 언제 사용해야하는 이유는 무엇입니까?

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 예외를 발생시키지 않고 기본적으로 죽은 참조를 제거하는 데 유용합니다.

캐스케이드 삭제시 :

하위 테이블의 행을 삭제 하려는 경우 해당 테이블이 상위 테이블에서 삭제 된 경우 .

경우 삭제 캐스케이드에 다음 사용되지 않는 오류가 위해 발생합니다 참조 무결성 .

캐스케이드 ON시 :

기본 키의 변경 사항 을 외래 키로 업데이트 하려는 경우

과거의 나쁜 경험으로 인해 "On Delete Cascade"(및 기타) 사용을 금지하는 DBA 및 / 또는 "회사 정책"에 대해 들었습니다. 어떤 경우에는 한 남자가 서로를 부르는 세 가지 방아쇠를 썼습니다. 하나의 idjit의 조치로 인해 복구 3 일 동안 트리거가 완전히 금지되었습니다.

물론 일부 하위 데이터를 보존해야하는 경우와 같이 "삭제시 계단식"대신 트리거가 필요합니다. 그러나 다른 경우에는 On Delete 캐스케이드 방법을 사용하는 것이 완벽하게 유효합니다. "삭제시 계단식"의 주요 장점은 모든 하위 항목을 캡처한다는 것입니다. 사용자 지정 작성 트리거 / 저장 프로 시저가 올바르게 코딩되지 않으면 그렇지 않을 수 있습니다.

개발자는 개발 내용과 사양에 따라 결정을 내릴 수 있어야한다고 생각합니다. 나쁜 경험에 근거한 카펫 금지는 기준이되어서는 안됩니다. "절대 사용하지 않음"사고 과정은 드라코 니안입니다. 매번 판단 호출이 필요하며 비즈니스 모델이 변경됨에 따라 변경됩니다.

이것이 개발의 전부가 아닙니까?

코드에서 수행하지 않고 연속 삭제를 수행하는 한 가지 이유는 성능을 향상시키기위한 것입니다.

사례 1 : 계단식 삭제

 DELETE FROM table WHERE SomeDate < 7 years ago;

사례 2 : 계단식 삭제없이

 FOR EACH R IN (SELECT FROM table WHERE SomeDate < 7 years ago) LOOP
   DELETE FROM ChildTable WHERE tableId = R.tableId;
   DELETE FROM table WHERE tableId = R.tableid;
   /* More child tables here */
 NEXT

두 번째로, 계단식 삭제로 하위 테이블을 추가하면 사례 1의 코드가 계속 작동합니다.

관계의 의미가 "일부"인 캐스케이드 만 넣을 것입니다. 그렇지 않으면 다음과 같은 작업을 수행 할 때 일부 바보가 데이터베이스의 절반을 삭제합니다.

DELETE FROM CURRENCY WHERE CurrencyCode = 'USD'

SQL Server에서 명시 적으로 요청하지 않은 삭제 또는 업데이트를 피하려고합니다.

계단식 또는 트리거 사용을 통해. 그들은 버그를 추적하려고 할 때나 성능 문제를 진단 할 때 어느 정도 시간을 허비하는 경향이 있습니다.

내가 사용하는 곳은별로 노력하지 않아도 일관성을 보장하는 것입니다. 동일한 효과를 얻으려면 저장 프로 시저를 사용해야합니다.

나는 여기의 다른 사람들과 마찬가지로 캐스케이드 삭제가 실제로 거의 도움이되지 않는다는 것을 알게됩니다 (다른 테이블에서 참조 된 데이터를 삭제하는 것은 그리 큰 일이 아닙니다. 테이블이 많으면 스크립트를 사용하여 간단히 자동화하십시오). 누군가 실수로 캐스케이드하여 복원하기 어려운 중요한 데이터를 삭제하는 경우

내가 사용하는 유일한 경우는 테이블 테이블의 데이터가 엄격하게 제어되고 (예 : 제한된 권한) 확인 된 제어 된 프로세스 (예 : 소프트웨어 업데이트)를 통해서만 업데이트되거나 삭제되는 경우입니다.

R의 일부 튜플에서 발견 된 외래 키 값을 제거하는 S의 삭제 또는 업데이트는 다음 세 가지 방법 중 하나로 처리 할 수 ​​있습니다.

1. 배제
2. 번식
3. 무효.

전파를 계단식이라고합니다.

두 가지 경우가 있습니다.

‣ S의 튜플이 삭제 된 경우이를 참조한 R 튜플을 삭제하십시오.

‣ S의 튜플이 업데이트 된 경우이를 참조하는 R 튜플의 값을 업데이트하십시오.

다른 버전의 여러 모듈이있는 시스템에서 작업하는 경우 계단식 삭제 항목이 PK 홀더의 일부이거나 소유 된 경우 매우 유용 할 수 있습니다. 그렇지 않으면 모든 모듈이 PK 소유자를 삭제하기 전에 종속 항목을 정리하기 위해 즉시 패치가 필요하거나 외래 키 관계가 완전히 생략되어 정리가 올바르게 수행되지 않으면 시스템에 많은 쓰레기가 남을 수 있습니다.

계단식 삭제가 꽤 오랫동안 권장되지 않은 후 이미 존재하는 두 테이블 사이의 새 교차 테이블에 대한 계단식 삭제 (삭제 교차 만)를 소개했습니다. 데이터가 손실되는 경우에도 그렇게 나쁘지 않습니다.

그러나 열거 형과 같은 목록 테이블에서는 나쁜 점이 있습니다. 누군가가 테이블 "색상"에서 항목 13-노란색을 삭제하면 데이터베이스의 모든 노란색 항목이 삭제됩니다. 또한, 이들은 모두 삭제-삽입-전체 방식으로 업데이트되어 참조 무결성이 완전히 생략됩니다. 물론 그것은 틀렸지 만, 진정한 참조 무결성의 도입이 예기치 않은 부작용의 위험에 처해있는 상태에서 수년 동안 실행되었던 복잡한 소프트웨어를 어떻게 변화시킬 것입니까?

또 다른 문제는 기본 외래 키 값이 기본 키가 삭제 된 후에도 유지되어야하는 경우입니다. 원래 FK에 대해 삭제 표시 열과 ON DELETE SET NULL 옵션을 만들 수 있지만 중복 키 (PK 삭제 후 제외) 키 값을 유지하려면 트리거 또는 특정 코드가 다시 필요합니다.

계단식 삭제는 물리적 데이터베이스에서 논리적 슈퍼 유형 및 하위 유형 엔터티를 구현할 때 매우 유용합니다.

별도의 수퍼 유형 및 하위 유형 테이블을 사용하여 수퍼 유형 / 하위 유형을 물리적으로 구현하는 경우 (모든 하위 유형 속성을 단일 물리적 수퍼 유형 테이블로 롤업하는 것과 대조적으로) 일대일 이러한 테이블과 문제 간의 관계는 기본 키를이 테이블간에 100 % 동기화하는 방법이됩니다.

계단식 삭제는 다음과 같은 경우에 매우 유용한 도구입니다.

1) 수퍼 유형 레코드를 삭제하면 해당 단일 하위 유형 레코드도 삭제해야합니다.

2) 하위 유형 레코드를 삭제하면 수퍼 유형 레코드도 삭제해야합니다. 이는 하위 유형 테이블에 "중재하지 않은"삭제 트리거를 구현하여 해당 상위 유형 레코드를 이동하고 삭제하는 방식으로 하위 유형 레코드를 삭제합니다.

이러한 방식으로 계단식 삭제를 사용하면 수퍼 유형 레코드를 먼저 삭제하는지 또는 하위 유형 레코드를 먼저 삭제하는지에 관계없이 고아 슈퍼 유형 또는 하위 유형 레코드가 존재하지 않습니다.