"ON UPDATE CASCADE"를 사용하는 경우

"ON DELETE CASCADE"를 정기적으로 사용하지만 어떤 상황에서 유용 할 지 확신 할 수 없으므로 "ON UPDATE CASCADE"를 사용하지 않습니다.

논의를 위해 코드를 보자.

CREATE TABLE parent (
    id INT NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (id)
);

CREATE TABLE child (
    id INT NOT NULL AUTO_INCREMENT, parent_id INT,
    INDEX par_ind (parent_id),
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
);

"ON DELETE CASCADE"의 경우 부모가있는 부모를 id삭제하면 자식이있는 레코드 parent_id = parent.id가 자동으로 삭제됩니다. 문제 없습니다.

1. 이것은 "ON UPDATE CASCADE"가 id부모가 업데이트 될 때 동일한 작업을 수행한다는 것을 의미 합니까?

2. (1)이 true 인 경우 "ON UPDATE CASCADE"를 parent.id업데이트 할 수없는 경우 ( AUTO_INCREMENT또는 항상로 설정 한 경우) 업데이트 할 수없는 경우 "ON UPDATE CASCADE"를 사용할 필요가 없음을 의미 합니다 TIMESTAMP. 맞습니까?

3. (2)가 맞지 않으면, 어떤 다른 상황에서 "ON UPDATE CASCADE"를 사용해야합니까?

4. child.parent_id존재하지 않는 것으로 업데이트 (어떤 이유로) 하면 자동으로 삭제됩니까?

글쎄, 위의 질문 중 일부는 프로그래밍 방식으로 이해하기 위해 테스트 할 수 있지만 데이터베이스 공급 업체에 의존하는지 여부를 알고 싶습니다.

약간의 빛을 비추십시오.

기본 키가 자동으로 증가 된 ID 값인 경우 ON UPDATE CASCADE를 실제로 사용하지 않을 것입니다.

그러나 기본 키가 10 자리 UPC 바코드이고 확장으로 인해 13 자리 UPC 바코드로 변경해야한다고 가정 해 봅시다. 이 경우 ON UPDATE CASCADE를 사용하면 기본 키 값을 변경할 수 있으며 값에 대한 외래 키 참조가있는 테이블이 그에 따라 변경됩니다.

# 4를 참조하면 자식 ID를 부모 테이블에없는 것으로 변경하고 참조 무결성이있는 경우 외래 키 오류가 발생합니다.

1. 예, 예를 들어 UPDATE parent SET id = 20 WHERE id = 10모든 하위 항목 을 수행 하면 parent_id가 10 인 경우에도 20으로 업데이트됩니다.

2. 외래 키가 참조하는 필드를 업데이트하지 않으면이 설정이 필요하지 않습니다

3. 다른 용도로는 생각할 수 없습니다.

4. 외래 키 제약 조건이 실패하기 때문에 그렇게 할 수 없습니다.

나는 당신이 요점을 거의 못 박았다고 생각합니다!

데이터베이스 디자인 모범 사례를 따르고 기본 키를 업데이트 할 수없는 경우 (항상 그래야한다고 생각되는 경우)에는 ON UPDATE CASCADE절이 필요하지 않습니다 .

Zed 는 기본 키로 자연 키 (예 : 데이터베이스 테이블의 일반 필드) 를 사용하는 경우 기본 키를 업데이트해야하는 특정 상황이있을 수 있다고 지적했습니다. 최근의 또 다른 예는 ISBN (International Standard Book Numbers)으로, 얼마 전에 10 자리에서 13 자리 숫자로 변경되었습니다.

대리 사용을 선택한 경우에는 그렇지 않습니다. (예 : 인공적으로 시스템에서 생성 된) 키를 기본 키 (가장 드문 경우를 제외하고 가장 선호하는 선택) .

결국 기본 키가 변경되지 않으면 ON UPDATE CASCADE절이 필요하지 않습니다 .

마크

며칠 전에 나는 방아쇠에 문제가 있었고, 그것이 ON UPDATE CASCADE유용 할 수 있다는 것을 알았습니다 . 이 예제를 살펴보십시오 (PostgreSQL).

CREATE TABLE club
(
    key SERIAL PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE band
(
    key SERIAL PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE concert
(
    key SERIAL PRIMARY KEY,
    club_name TEXT REFERENCES club(name) ON UPDATE CASCADE,
    band_name TEXT REFERENCES band(name) ON UPDATE CASCADE,
    concert_date DATE
);

내 문제에서는 콘서트 테이블을 업데이트하기 위해 추가 작업 (트리거)을 정의해야했습니다. 이러한 작업은 club_name 및 band_name을 수정해야했습니다. 나는 참조 때문에 그것을 할 수 없었다. 콘서트를 수정 한 다음 클럽과 밴드 테이블을 처리 할 수 ​​없었습니다. 다른 방법으로는 할 수 없었습니다. ON UPDATE CASCADE문제를 해결하는 열쇠였습니다.

내 의견은 주로 포인트 # 3을 참조합니다 : 부모 키를 업데이트 할 수 없다고 가정하면 ON UPDATE CASCADE는 어떤 상황에서 적용됩니까? 한 가지 경우가 있습니다.

여러 위성 데이터베이스를 마스터와 병합 해야하는 복제 시나리오를 다루고 있습니다. 각 위성은 동일한 테이블에서 데이터를 생성하므로 테이블을 마스터에 병합하면 고유성 제약 조건이 위반됩니다. 병합 할 때마다 키를 다시 증가시키는 솔루션의 일부로 ON UPDATE CASCADE를 사용하려고합니다. UPDATE CASCADE는 프로세스의 일부를 자동화하여이 프로세스를 단순화해야합니다.

훌륭한 질문입니다. 어제 같은 질문이있었습니다. "ON UPDATE CASCADE"와 같은 것이 있으면이 문제, 특히 SEARCHED에 대해 생각했고 다행히도 SQL 디자이너도 그것에 대해 생각했습니다. 나는 Ted.strauss에 동의하며 Noran의 사례에 대해서도 언급했다.

언제 사용 했습니까? 테드가 지적한 것처럼, 한 번에 여러 데이터베이스를 처리 할 때 하나의 테이블에서 하나의 수정으로 테드가 "위성 데이터베이스"라고 부르는 것에 어떤 종류의 재생산이 있더라도 원래의 상태로 유지할 수 없습니다. ID, 그리고 어떤 이유로 든 이전 데이터에 대한 데이터를 업데이트 할 수없는 경우 (예 : 권한으로 인해 또는 일시적인 경우에 빠른 검색을하는 경우) 전체 정규화 규칙을 절대적으로 존중할 필요는 없습니다. 단순히 매우 짧은 수명의 유틸리티이기 때문입니다)

따라서 두 가지 점에 동의합니다.

(A.) 그렇습니다. 더 좋은 디자인은 그것을 피할 수 있습니다. 그러나

(B.) 마이그레이션, 데이터베이스 복제 또는 응급 상황 해결의 경우 운 좋게도 검색을했을 때 존재했던 훌륭한 도구입니다.